Re: [RFC v1 0/5] Move kvfree_rcu() into SLAB

[Uladzislau Rezki <urezki@gmail.com>]

On Thu, Dec 12, 2024 at 11:30:36AM +0100, Vlastimil Babka wrote:
> On 12/10/24 17:40, Uladzislau Rezki (Sony) wrote:
> > Hello!
> 
> Hi and thanks!
> 
> > This series is based on v6.12 kernel.
> 
> Could it be rebased to v6.13-rc1, which is a basis for most -next branches?
> Right now patch 5 doesn't apply on v6.13-rc1.
> 
> Please also Cc all slab maintainers/reviewers.
> 
> > It is an attempt to move the kvfree_rcu()
> > into MM from the kernel/rcu/ place. I split the series into a few patches so it
> > is easier to follow a migration process.
> 
> I think this is not the best approach. The individual diffs are not easy to
> follow because they copy code or delete code separately, and not move it in
> a single commit. I get a much better overview when I diff the whole series
> against baseline, then git highlights pure moves and local changes nicely.
> 
> Having moves recorded properly would also make it possible for "git blame
> -C" to show changes that were made in the old file before the move, but with
> copy and deletion in separate commits it doesn't work.
> (but note it seems it doesn't work so great even if I squash everything to
> one patch - were the functions reodered?)
> 
> And with this approach you also need the temporary changes.
> 
> What I think could work better is to do:
> - preparatory changes in the existing location
>   - splitting out kvfree_rcu_init() and calling separately in start_kernel()
>   - renaming shrinkers
>   - adjusting the names passed to trace_rcu_...()
>   - maybe even adding the CONFIG_TINY_RCU guards even if redundant
> - one big move of code between files, hopefully needing no or minimal
> adjustments after the preparatory steps
> 
> Makes sense?
> 
See v2. We can go that way, so it makes sense to me.

Thank you.

--
Uladzislau Rezki