On Wed, Aug 24, 2022 at 12:59 PM Kumar Kartikeya Dwivedi <memxor@xxxxxxxxx> wrote: > > On Fri, 19 Aug 2022 at 23:43, Alexei Starovoitov > <alexei.starovoitov@xxxxxxxxx> wrote: > > > > From: Alexei Starovoitov <ast@xxxxxxxxxx> > > > > SLAB_TYPESAFE_BY_RCU makes kmem_caches non mergeable and slows down > > kmem_cache_destroy. All bpf_mem_cache are safe to share across different maps > > and programs. Convert SLAB_TYPESAFE_BY_RCU to batched call_rcu. This change > > solves the memory consumption issue, avoids kmem_cache_destroy latency and > > keeps bpf hash map performance the same. > > > > Signed-off-by: Alexei Starovoitov <ast@xxxxxxxxxx> > > Makes sense, there was a call_rcu_lazy work from Joel (CCed) on doing > this batching using a timer + max batch count instead, I wonder if > that fits our use case and could be useful in the future when it is > merged? > > https://lore.kernel.org/rcu/20220713213237.1596225-2-joel@xxxxxxxxxxxxxxxxx Thanks for the pointer. It looks orthogonal. timer based call_rcu is for power savings. I'm not sure how it would help here. Probably wouldn't hurt. But explicit waiting_for_gp list is necessary here, because two later patches (sleepable support and per-cpu rcu-safe freeing) are relying on this patch.
