Linux: Report reclaimable memory to kernel as such

[amotin]

Linux provides SLAB_RECLAIM_ACCOUNT and __GFP_RECLAIMABLE flags to mark memory allocations that can be freed via shinker calls. It should allow kernel to tune and group such allocations for lower memory fragmentation and better reclamation under pressure.

This patch marks as reclaimable most of ARC memory, directly evictable via ZFS shrinker, plus also dnode/znode/sa memory, indirectly evictable via kernel's superblock shrinker.

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.

[tonyhutter]

Could we get one more reviewer on this one?

[adamdmoss]

While I think the changes (and goals!) make sense, I don't appear to be able to see a difference in either the kernel's accounting of free/available memory (casually tested via 'free' and similar) or general eviction behavior. Tested (as I said, casually - filling ARC, applying slow or fast memory pressure, applying non-ARC pagecache pressure, etc, eyeing 'free' and other end-user memory stat gatherers) with a Linux 6.8 kernel.

Is there a specific stat or testing pattern where this is clearly functional and beneficial? Thanks.

[amotin]

@adamdmoss SLAB_RECLAIM_ACCOUNT memory should be included into SReclaimable in /proc/meminfo and then into available memory, which as I see should be used by different balloon drivers. __GFP_RECLAIMABLE I haven't found to be reported directly, but I understand it to be grouped together as Reclaimable migration type, as reported in /proc/pagetypeinfo.

[adamdmoss]

Thanks, that makes some sense.
Looks like it's my confusion; for some reason I thought arc contents were slab-allocated, but it appears they're not (according to /proc/meminfo and slabinfo); arc headers and some other metadata are slab-allocated but the contents (mostly held in ABDs I think?) aren't.