> On Mar 16, 2023, at 9:17 AM, Zhuo, Qiuxu <qiuxu.zhuo@xxxxxxxxx> wrote: > > >> >> From: Paul E. McKenney <paulmck@xxxxxxxxxx> >> [...] >>>> >>>> How about to pull the rcu_scale_cleanup() function after >> kfree_scale_cleanup(). >>>> This groups kfree_* functions and groups rcu_scale_* functions. >>>> Then the code would look cleaner. >>>> So, do you think the changes below are better? >>> >>> IMHO, I don't think doing such a code move is better. Just add a new >>> header file and declare the function there. But see what Paul says >>> first. >> >> This situation is likely to be an early hint that the kvfree_rcu() testing should >> be split out from kernel/rcu/rcuscale.c. > > Another is that it's a bit expensive to create a new header file just for > eliminating a function declaration. ;-) What is so expensive about new files? It is a natural organization structure. > So, if no objections, I'd like to send out the v2 patch with the updates below: > > - Move rcu_scale_cleanup() after kfree_scale_cleanup() to eliminate the > declaration of kfree_scale_cleanup(). Though this makes the patch bigger, > get the file rcuscale.c much cleaner. > > - Remove the unnecessary step "modprobe torture" from the commit message. > > - Add the description for why move rcu_scale_cleanup() after > kfree_scale_cleanup() to the commit message. Honestly if you are moving so many lines around, you may as well split it out into a new module. The kfree stuff being clubbed in the same file has also been a major annoyance. - Joel > Thanks! > -Qiuxu > >> [...]
