]> www.infradead.org Git - users/jedix/linux-maple.git/commit
slab: add sheaf support for batching kfree_rcu() operations
authorVlastimil Babka <vbabka@suse.cz>
Thu, 4 Jul 2024 08:06:07 +0000 (10:06 +0200)
committerLiam R. Howlett <Liam.Howlett@oracle.com>
Tue, 4 Mar 2025 16:35:05 +0000 (11:35 -0500)
commit0649356335b8660c788d298d6ebde341c0089cdb
tree2b30fad563e238cc7a15f5ce7d5f4c1f63fff86d
parenteca0a41c06b619a7d115f31723462d215959431d
slab: add sheaf support for batching kfree_rcu() operations

Extend the sheaf infrastructure for more efficient kfree_rcu() handling.
For caches with sheaves, on each cpu maintain a rcu_free sheaf in
addition to main and spare sheaves.

kfree_rcu() operations will try to put objects on this sheaf. Once full,
the sheaf is detached and submitted to call_rcu() with a handler that
will try to put in in the barn, or flush to slab pages using bulk free,
when the barn is full. Then a new empty sheaf must be obtained to put
more objects there.

It's possible that no free sheaves are available to use for a new
rcu_free sheaf, and the allocation in kfree_rcu() context can only use
GFP_NOWAIT and thus may fail. In that case, fall back to the existing
kfree_rcu() machinery.

Expected advantages:
- batching the kfree_rcu() operations, that could eventually replace the
  existing batching
- sheaves can be reused for allocations via barn instead of being
  flushed to slabs, which is more efficient
  - this includes cases where only some cpus are allowed to process rcu
    callbacks (Android)

Possible disadvantage:
- objects might be waiting for more than their grace period (it is
  determined by the last object freed into the sheaf), increasing memory
  usage - but the existing batching does that too?

Only implement this for CONFIG_KVFREE_RCU_BATCHED as the tiny
implementation favors smaller memory footprint over performance.

Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
mm/slab.h
mm/slab_common.c
mm/slub.c