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: Make call_rcu() lazy only when CONFIG_RCU_LAZY is enabled
Date:   Thu, 20 Oct 2022 04:42:05 -0400
Message-Id: <D7F0EE3F-0A06-4868-87E3-B88B9BD6480C@joelfernandes.org>
References: <20221019233419.GI5600@paulmck-ThinkPad-P17-Gen-1>
Cc:     Zqiang <qiang1.zhang@intel.com>, frederic@kernel.org,
        rcu@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20221019233419.GI5600@paulmck-ThinkPad-P17-Gen-1>
To:     paulmck@kernel.org
Precedence: bulk


> On Oct 19, 2022, at 7:34 PM, Paul E. McKenney <paulmck@kernel.org> wrote:
>=20
> =EF=BB=BFOn Wed, Oct 19, 2022 at 02:25:29PM -0400, Joel Fernandes wrote:
>>=20
>>=20
>>>> On Oct 19, 2022, at 1:45 PM, Paul E. McKenney <paulmck@kernel.org> wrot=
e:
>>>=20
>>> =EF=BB=BFOn Wed, Oct 19, 2022 at 08:12:30AM -0400, Joel Fernandes wrote:=

>>>>> On Oct 19, 2022, at 8:10 AM, Joel Fernandes <joel@joelfernandes.org> w=
rote:
>>>>>>> On Oct 19, 2022, at 6:34 AM, Zqiang <qiang1.zhang@intel.com> wrote:
>>>>>>>=20
>>>>>>> =EF=BB=BFCurrently, regardless of whether the CONFIG_RCU_LAZY is ena=
bled,
>>>>>>> invoke the call_rcu() is always lazy, it also means that when
>>>>>>> CONFIG_RCU_LAZY is disabled, invoke the call_rcu_flush() is also
>>>>>>> lazy. therefore, this commit make call_rcu() lazy only when
>>>>>>> CONFIG_RCU_LAZY is enabled.
>>>>=20
>>>> First, good eyes!  Thank you for spotting this!!

Indeed.

>>>>>>> Signed-off-by: Zqiang <qiang1.zhang@intel.com>
>>>>>>> ---
>>>>>>> kernel/rcu/tree.c | 8 +++++++-
>>>>>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>>>>>>=20
>>>>>>> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
>>>>>>> index abc615808b6e..97ef602da3d5 100644
>>>>>>> --- a/kernel/rcu/tree.c
>>>>>>> +++ b/kernel/rcu/tree.c
>>>>>>> @@ -2839,7 +2839,6 @@ void call_rcu_flush(struct rcu_head *head, rcu=
_callback_t func)
>>>>>>> return __call_rcu_common(head, func, false);
>>>>>>> }
>>>>>>> EXPORT_SYMBOL_GPL(call_rcu_flush);
>>>>>>> -#endif
>>>>>>>=20
>>>>>>> /**
>>>>>>> * call_rcu() - Queue an RCU callback for invocation after a grace pe=
riod.
>>>>>>> @@ -2890,6 +2889,13 @@ void call_rcu(struct rcu_head *head, rcu_call=
back_t func)
>>>>>>> return __call_rcu_common(head, func, true);
>>>>>>> }
>>>>>>> EXPORT_SYMBOL_GPL(call_rcu);
>>>>>>> +#else
>>>>>>> +void call_rcu(struct rcu_head *head, rcu_callback_t func)
>>>>>>> +{
>>>>>>> +    return __call_rcu_common(head, func, false);
>>>>>=20
>>>>> Thanks. Instead of adding new function, you can also pass IS_ENABLED(C=
ONFIG=E2=80=A6) to the existing function of the same name.
>>>=20
>>> I do like this approach better -- less code, more obvious what is going o=
n.
>>=20
>> Sounds good. Zqiang, do you mind updating your patch along these lines? T=
hat way you get the proper attribution.

Acked that patch.

>> More comments below:
>>>=20
>>>>> Looks like though I made every one test the patch without having to en=
able the config option ;-). Hey, I=E2=80=99m a half glass full kind of guy, w=
hy do you ask?
>>>>>=20
>>>>> Paul, I=E2=80=99ll take a closer look once I=E2=80=99m at the desk, bu=
t would you prefer to squash a diff into the existing patch, or want a new p=
atch altogether?
>>>>=20
>>>> On the other hand, what I=E2=80=99d want is to nuke the config option a=
ltogether or make it default y, we want to catch issues sooner than later.
>>>=20
>>> That might be what we do at some point, but one thing at a time.  Let's
>>> not penalize innocent bystanders, at least not just yet.
>>=20
>> It=E2=80=99s a trade off, I thought that=E2=80=99s why we wanted to have t=
he binary search stuff. If no one reports issue on Linux-next, then that cod=
e won=E2=80=99t be put to use in the near future at least.
>=20
> Well, not to put too fine a point on it, but we currently really are
> exposing -next to lazy call_rcu().  ;-)

This is true. I think I assumed nobody will enable a default off config opti=
on but I probably meant a smaller percentage will.

>>> I do very strongly encourage the ChromeOS and Android folks to test this=

>>> very severely, however.
>>=20
>> Agreed. Yes that will happen, though I have to make a note for Android fo=
lks other than Vlad, to backports these (and enable the config option), care=
fully! Especially on pre-5.15 kernels. Luckily I had to do this (not so triv=
ial) exercise myself.
>=20
> And this is another situation in which the binary search stuff may prove
> extremely useful.

Agreed. Thanks. Very least I owe per-rdp splitting of the hashtable, to that=
 code.  Steven and me talked today that probably the hashtable can go into t=
he rcu_segcblist itself, and protect it by the nocb lock.

Thanks,

 - Joel


>                            Thanx, Paul
>=20
>> Thanks!
>>=20
>> - Joel
>>=20
>>>=20
>>>                           Thanx, Paul
>>>=20
>>>> Thanks.
>>>>=20
>>>>>=20
>>>>> Thanks.
>>>>>=20
>>>>> - Joel
>>>>>=20
>>>>>=20
>>>>>> +}
>>>>>> +EXPORT_SYMBOL_GPL(call_rcu);
>>>>>> +#endif
>>>>>>=20
>>>>>> /* Maximum number of jiffies to wait before draining a batch. */
>>>>>> #define KFREE_DRAIN_JIFFIES (5 * HZ)
>>>>>> --=20
>>>>>> 2.25.1
>>>>>>=20