Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 11 May 2023 06:56:54 -0700
From:   "Paul E. McKenney" <paulmck@kernel.org>
To:     "Zhuo, Qiuxu" <qiuxu.zhuo@intel.com>
Cc:     Joel Fernandes <joel@joelfernandes.org>,
        "rcu@vger.kernel.org" <rcu@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "kernel-team@meta.com" <kernel-team@meta.com>,
        "rostedt@goodmis.org" <rostedt@goodmis.org>
Subject: Re: [PATCH rcu 3/6] rcu/rcuscale: Move rcu_scale_*() after
 kfree_scale_cleanup()
Message-ID: <7a91a10d-3518-4452-b9ca-51240f00d29f@paulmck-laptop>
Reply-To: paulmck@kernel.org
References: <7ffd4a5d-61e9-4b4c-a312-a85bcde08c39@paulmck-laptop>
 <20230510171238.2189921-3-paulmck@kernel.org>
 <CAEXW_YTHNbzdSn3RpJwnwKZOJX=rGdMabfsCw0ZuMZhsXZMjQA@mail.gmail.com>
 <IA1PR11MB6171FA965F8FF915621482E789749@IA1PR11MB6171.namprd11.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <IA1PR11MB6171FA965F8FF915621482E789749@IA1PR11MB6171.namprd11.prod.outlook.com>
Precedence: bulk

On Thu, May 11, 2023 at 07:01:59AM +0000, Zhuo, Qiuxu wrote:
> > From: Joel Fernandes <joel@joelfernandes.org>
> > Sent: Thursday, May 11, 2023 1:23 PM
> > To: Paul E. McKenney <paulmck@kernel.org>
> > Cc: rcu@vger.kernel.org; linux-kernel@vger.kernel.org; kernel-
> > team@meta.com; rostedt@goodmis.org; Zhuo, Qiuxu
> > <qiuxu.zhuo@intel.com>
> > Subject: Re: [PATCH rcu 3/6] rcu/rcuscale: Move rcu_scale_*() after
> > kfree_scale_cleanup()
> > 
> > On Wed, May 10, 2023 at 10:12 AM Paul E. McKenney <paulmck@kernel.org>
> > wrote:
> > >
> > > From: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
> > >
> > > This code-movement-only commit moves the rcu_scale_cleanup() and
> > > rcu_scale_shutdown() functions to follow kfree_scale_cleanup().
> > > This is code movement is in preparation for a bug-fix patch that
> > > invokes
> > > kfree_scale_cleanup() from rcu_scale_cleanup().
> > >
> > > Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
> > > Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> > > ---
> > >  kernel/rcu/rcuscale.c | 194
> > > +++++++++++++++++++++---------------------
> > >  1 file changed, 97 insertions(+), 97 deletions(-)
> > 
> > I wish diff was better at showing what really changed. The meld tool can help
> > but its gui...
> > 
> > Should I run meld later (I'm out at a conference so no access to meld-capable
> > machines) or are we sufficiently confident that the lines were moved as-is ? :)
> > 
> 
> Thank you, Joel for this concern. Good to know the meld diff GUI tool. 
> I just run the command below and confirmed that the lines were moved 
> as-is: rcu_scale_{cleanup,shutdown}() follows kfree_scale_cleanup().
> You may double check it ;-).
> 
>       meld --diff ./rcuscale.c.before ./rcuscale.c.after

Nice, thank you both!

Another option is to check out the commit corresponding to this patch,
then do "git blame -M kernel/rcu/rcuscale.c".  Given a move-only commit,
there should be no line tagged with this commit's SHA-1.

They say that another option is to use "git diff --color-moved", which
colors the changes.  That it does, but I am hard-pressed to work out
exactly what distinguishes a moved hunk from an added or removed hunk.
Fall colors vs. winter colors?  Exterior vs. interior?  Any particular
decade in the endless rush of changes to fashion?  Perhaps someone with
normal color vision (to say nothing of better fashion sense) could try it.

On the other hand: "default: Is a synonym for zebra. This may change to
a more sensible mode in the future."  So maybe it is not just me.  ;-)

You can also apparently choose colors using "color.diff.newMoved" and
"color.diff.oldMoved" when using "--color-moved=plain".

But "git diff --color-moved=dimmed-zebra" might be more to the point for
someone like me.  I would need to experiment with it more in order to
confirm my hypotheses about what it is doing.  To say nothing of building
trust in it.  Plus I have to open a color terminal to use it effectively.
So maybe "git blame -M" continues to be the tool for me?

							Thanx, Paul