On Wed, Aug 24, 2022 at 8:35 PM Joel Fernandes <joel@xxxxxxxxxxxxxxxxx> wrote: > > On Wed, Aug 24, 2022 at 8:14 PM Alexei Starovoitov > <alexei.starovoitov@xxxxxxxxx> wrote: > > > > 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. > > Hello Kumar and Alexei, > > Kumar thanks for the CC. I am seeing this BPF work for the first time > so have not gone over it too much - but in case the waiting is > synchronous by any chance, call_rcu_lazy() could hurt. The idea is to > only queue callbacks that are not all that important to the system > while keeping it quiet (power being the primary reason but Daniel > Bristot would concur it brings down OS noise and helps RT as well). Just as FYI, I see rcu_barrier() used in Alexei's patch - that will flush the lazy CBs to keep rcu_barrier() both correct and performant. At that point call_rcu_lazy() is equivalent to call_rcu() as we no longer kept the callbacks a secret from the rest of the system. Thanks, - Joel