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;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Joel Fernandes <joel@joelfernandes.org>
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH rcu 3/6] rcu/rcuscale: Move rcu_scale_*() after kfree_scale_cleanup()
Date:   Thu, 11 May 2023 21:15:17 -0700
Message-Id: <30F06C03-6950-4E2B-B3CE-3939B3CDD295@joelfernandes.org>
References: <IA1PR11MB6171B1AD7716B95B0B2C683889759@IA1PR11MB6171.namprd11.prod.outlook.com>
Cc:     paulmck@kernel.org, rcu@vger.kernel.org,
        linux-kernel@vger.kernel.org, kernel-team@meta.com,
        rostedt@goodmis.org
In-Reply-To: <IA1PR11MB6171B1AD7716B95B0B2C683889759@IA1PR11MB6171.namprd11.prod.outlook.com>
To:     "Zhuo, Qiuxu" <qiuxu.zhuo@intel.com>
Precedence: bulk


> On May 11, 2023, at 8:20 PM, Zhuo, Qiuxu <qiuxu.zhuo@intel.com> wrote:
>=20
> =EF=BB=BF
>>=20
>> From: Paul E. McKenney <paulmck@kernel.org>
>> ...
>>>> I wish diff was better at showing what really changed. The meld tool
>>>> can help but its gui...
>>>>=20
>>>> 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 ? :)
>>>>=20
>>>=20
>>> 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 ;-).
>>>=20
>>>      meld --diff ./rcuscale.c.before ./rcuscale.c.after
>>=20
>> Nice, thank you both!
>>=20
>> Another option is to check out the commit corresponding to this patch, th=
en
>> 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.
>=20
> Just had a good experiment with the "git blame -M" option:=20
> - Used this option to prove a move-only commit quickly (no line tagged wit=
h that commit) (the fastest method to me).=20
> - Then just only needed to quickly check the positions of the moved code c=
hunk by myself (easy). =20
>=20
> Thank you, Paul for sharing this. It's very useful to me.=20

Looks good to me as well and thank you both for sharing the tips.

 - Joel


>=20
>> They say that another option is to use "git diff --color-moved", which co=
lors
>> the changes.  That it does, but I am hard-pressed to work out exactly wha=
t
>> distinguishes a moved hunk from an added or removed hunk.
>> Fall colors vs. winter colors?  Exterior vs. interior?  Any particular de=
cade in
>> the endless rush of changes to fashion?  Perhaps someone with normal colo=
r
>> vision (to say nothing of better fashion sense) could try it.
>>=20
>> 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.  ;-)
>>=20
>> You can also apparently choose colors using "color.diff.newMoved" and
>> "color.diff.oldMoved" when using "--color-moved=3Dplain".
>>=20
>> But "git diff --color-moved=3Ddimmed-zebra" might be more to the point fo=
r
>> 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=

>=20
> Yup, this looks a bit painful for me too (need experiments to confirm hypo=
theses ...).=20
>=20
>> 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?
>>=20
>>                            Thanx, Paul