]> www.infradead.org Git - users/jedix/linux-maple.git/commit
slab: add sheaf support for batching kfree_rcu() operations
authorVlastimil Babka <vbabka@suse.cz>
Wed, 12 Mar 2025 16:10:18 +0000 (17:10 +0100)
committerLiam R. Howlett <Liam.Howlett@oracle.com>
Tue, 8 Apr 2025 20:01:05 +0000 (16:01 -0400)
commitaf5e179f365ae9bf6f87402e5ec0f19c02ce9646
tree4d0f3325b3f89c9248efd3ebf7b08c99c8ba9e91
parent5ee53f01686d4caf6f64cea80db2b75ac960c218
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 it 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>
Reviewed-by: Suren Baghdasaryan <surenb@google.com>
mm/slab.h
mm/slab_common.c
mm/slub.c