On Mon, Dec 16, 2024 at 03:20:44PM +0100, Vlastimil Babka wrote: > On 12/16/24 12:03, Uladzislau Rezki wrote: > > On Sun, Dec 15, 2024 at 06:30:02PM +0100, Vlastimil Babka wrote: > >> On 12/12/24 19:02, Uladzislau Rezki (Sony) wrote: > >> > Hello! > >> > > >> > This is v2. It is based on the Linux 6.13-rc2. The first version is > >> > here: > >> > > >> > https://lore.kernel.org/linux-mm/20241210164035.3391747-4-ure...@gmail.com/T/ > >> > > >> > The difference between v1 and v2 is that, the preparation process is > >> > done in original place instead and after that there is one final move. > >> > >> Looks good, will include in slab/for-next > >> > >> I think patch 5 should add more explanation to the commit message - the > >> subthread started by Christoph could provide content :) Can you summarize > >> so > >> I can amend the commit log? > >> > > I will :) > > > >> Also how about a followup patch moving the rcu-tiny implementation of > >> kvfree_call_rcu()? > >> > > As, Paul already noted, it would make sense. Or just remove a tiny > > implementation. > > AFAICS tiny rcu is for !SMP systems. Do they benefit from the "full" > implementation with all the batching etc or would that be unnecessary > overhead? > Yes, it is for a really small systems with low amount of memory. I see only one overhead it is about driving objects in pages. For a small system it can be critical because we allocate.
>From the other hand, for a tiny variant we can modify the normal variant by bypassing batching logic, thus do not consume memory(for Tiny case) i.e. merge it to a normal kvfree_rcu() path. After that we do not depend on CONFIG_RCU_TINY option. Probably we need also to perform some adaptation of regular kvfree_rcu() for a single CPU system. -- Uladzislau Rezki
