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 17:33:37 -0400
Message-Id: <DC93C5EB-91A5-4291-A642-8A57179930E4@joelfernandes.org>
References: <95331C23-3632-4E0B-9959-43CE159FE60F@joelfernandes.org>
Cc:     Zqiang <qiang1.zhang@intel.com>, frederic@kernel.org,
        rcu@vger.kernel.org, linux-kernel@vger.kernel.org,
        Steven Rostedt <rostedt@goodmis.org>
In-Reply-To: <95331C23-3632-4E0B-9959-43CE159FE60F@joelfernandes.org>
To:     paulmck@kernel.org
Precedence: bulk


> On Oct 20, 2022, at 2:46 PM, Joel Fernandes <joel@joelfernandes.org> wrote=
:
>>>=20
>>>>> More comments below:
>>>>>>=20
>>>>>>>> Looks like though I made every one test the patch without having to=
 enable the config option ;-). Hey, I=E2=80=99m a half glass full kind of gu=
y, why do you ask?
>>>>>>>>=20
>>>>>>>> Paul, I=E2=80=99ll take a closer look once I=E2=80=99m at the desk,=
 but would you prefer to squash a diff into the existing patch, or want a ne=
w patch altogether?
>>>>>>>=20
>>>>>>> On the other hand, what I=E2=80=99d want is to nuke the config optio=
n altogether 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 ha=
ve the binary search stuff. If no one reports issue on Linux-next, then that=
 code 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().  ;-)
>>>=20
>>> This is true. I think I assumed nobody will enable a default off config o=
ption but I probably meant a smaller percentage will.
>>>=20
>>>>>> I do very strongly encourage the ChromeOS and Android folks to test t=
his
>>>>>> very severely, however.
>>>>>=20
>>>>> Agreed. Yes that will happen, though I have to make a note for Android=
 folks other than Vlad, to backports these (and enable the config option), c=
arefully! Especially on pre-5.15 kernels. Luckily I had to do this (not so t=
rivial) exercise myself.
>>>>=20
>>>> And this is another situation in which the binary search stuff may prov=
e
>>>> extremely useful.
>>>=20
>>> Agreed. Thanks. Very least I owe per-rdp splitting of the hashtable, to t=
hat code.  Steven and me talked today that probably the hashtable can go int=
o the rcu_segcblist itself, and protect it by the nocb lock.
>>=20
>> I have to ask...
>>=20
>> How does this fit in with CPU-hotplug and callback migration?
>=20
> Yes it will require change and I already thought of that, have to update t=
he hashtable on all such events.
>=20
>> More to the point, what events would cause us to decide that this is
>> required?  For example, shouldn't we give your current binary-search
>> code at least a few chances to save the day?
>=20
> Totally, if you=E2=80=99re taking the patch as is, I would be very happy. A=
nd I=E2=80=99ll continue to improve it with the above. But I was not sure ye=
t if you=E2=80=99re taking it.
>=20
> I think it=E2=80=99s a worthwhile to take it for mainline in the current s=
tate and I=E2=80=99ll also add more data about callbacks to it in future (qu=
euing time of callback, etc) =E2=80=94 basically all the stuff I wanted to a=
dd to rcu_head.
>=20
> One reason for the above proposal is I also want to keep it turned on in p=
roduction, and the current solution cannot be, due to the global locking and=
 is not expected to be kept on in production. But is still a worthwhile addi=
tion for debug kernels IMO.

I realized while talking to Steve that the hashtable has to be per CPU if we=
 are to store more than a lazy flag, such as queuing timestamps. This is bec=
ause you can have multiple callbacks of the same function pointer queued on m=
ultiple CPUs. So you can have multiple timestamps to store. Same thing if we=
 stored automata. It=E2=80=99s per callback instance, not per callback funct=
ion.

Thanks,

 - Joel


>=20
> Thanks,
>=20
> - Joel
>=20
>=20
>>                           Thanx, Paul
>>=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