BRT: Change brt_pending_tree sorting order

[amotin]

It does not look important how exactly brt_pending_tree is sorted. When cloning large file, it is quite likely that all of its blocks have identical physical birth times, so comparing them first does not provide useful entropy, while accesses additional cache line. In most cases combination of vdev and offset provides unique result and physical birth time comparison is not even needed. Meanwhile, when traversing the tree inside brt_pending_apply(), it can be beneficial for dbuf cache and CPU cache hits to group processing by vdev and so by the per-VDEV BRT ZAPs.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[pjd]

So why not to compare offsets first? That contains the most entropy and would be optimal for single-disk pools.

[amotin]

So why not to compare offsets first? That contains the most entropy and would be optimal for single-disk pools.

@pjd vdev and offset in block pointer reside in the same cache line, so while there may indeed be an extra extra comparison, it does not cost that much, unlike physical birth, that is 72 bytes away. But comparing vdev first makes tree sorted on it first, that allows brt_pending_apply() to modify ZAPs for one VDEV at a time, improving caching efficiency and so performance there.