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
Subject: Re: [BUG] Re: Linux 6.4.4
Mime-Version: 1.0 (1.0)
From:   Joel Fernandes <joel@joelfernandes.org>
In-Reply-To: <4b231ce5-7bb8-4abf-9c40-04aa676d1e45@paulmck-laptop>
Cc:     linux-kernel@vger.kernel.org, stable@vger.kernel.org,
        rcu@vger.kernel.org, Greg KH <gregkh@linuxfoundation.org>
Date:   Mon, 24 Jul 2023 19:04:14 -0400
Message-Id: <123C6650-490B-4D08-96B4-39B118AD0054@joelfernandes.org>
References: <4b231ce5-7bb8-4abf-9c40-04aa676d1e45@paulmck-laptop>
To:     paulmck@kernel.org
Precedence: bulk


> On Jul 24, 2023, at 12:00 PM, Paul E. McKenney <paulmck@kernel.org> wrote:=

>=20
> =EF=BB=BFOn Mon, Jul 24, 2023 at 09:36:02AM -0400, Joel Fernandes wrote:
>>> On Sun, Jul 23, 2023 at 11:35=E2=80=AFPM Paul E. McKenney <paulmck@kerne=
l.org> wrote:
>>>=20
>>> On Mon, Jul 24, 2023 at 12:32:57AM +0000, Joel Fernandes wrote:
>>>> On Sun, Jul 23, 2023 at 10:19:27AM -0700, Paul E. McKenney wrote:
>>>>> On Sun, Jul 23, 2023 at 10:50:26AM -0400, Joel Fernandes wrote:
>>>>>>=20
>>>>>>=20
>>>>>> On 7/22/23 13:27, Paul E. McKenney wrote:
>>>>>> [..]
>>>>>>>=20
>>>>>>> OK, if this kernel is non-preemptible, you are not running TREE03,
>>>>>>> correct?
>>>>>>>=20
>>>>>>>> Next plan of action is to get sched_waking stack traces since I hav=
e a
>>>>>>>> very reliable repro of this now.
>>>>>>>=20
>>>>>>> Too much fun!  ;-)
>>>>>>=20
>>>>>> For TREE07 issue, it is actually the schedule_timeout_interruptible(1=
)
>>>>>> in stutter_wait() that is beating up the CPU0 for 4 seconds.
>>>>>>=20
>>>>>> This is very similar to the issue I fixed in New year in d52d3a2bf408=

>>>>>> ("torture: Fix hang during kthread shutdown phase")
>>>>>=20
>>>>> Agreed, if there are enough kthreads, and all the kthreads are on a
>>>>> single CPU, this could consume that CPU.
>>>>>=20
>>>>>> Adding a cond_resched() there also did not help.
>>>>>>=20
>>>>>> I think the issue is the stutter thread fails to move spt forward
>>>>>> because it does not get CPU time. But spt =3D=3D 1 should be very bri=
ef
>>>>>> AFAIU. I was wondering if we could set that to RT.
>>>>>=20
>>>>> Or just use a single hrtimer-based wait for each kthread?
>>>>=20
>>>> [Joel]
>>>> Yes this might be better, but there's still the issue that spt may not b=
e set
>>>> back to 0 in some future release where the thread gets starved.
>>>=20
>>> But if each thread knows the absolute time at which the current stutter
>>> period is supposed to end, there should not be any need for the spt
>>> variable, correct?
>>=20
>> Yes.
>>=20
>>>>>> But also maybe the following will cure it like it did for the shutdow=
n
>>>>>> issue, giving the stutter thread just enough CPU time to move spt for=
ward.
>>>>>>=20
>>>>>> Now I am trying the following and will let it run while I go do other=

>>>>>> family related things. ;)
>>>>>=20
>>>>> Good point, if this avoids the problem, that gives a strong indication=

>>>>> that your hypothesis on the root cause is correct.
>>>>=20
>>>> [Joel]
>>>> And the TREE07 issue is gone with that change!
>> [...]
>>>> Let me know what you think, thanks!
>>>=20
>>> If we can make the stutter kthread set an absolute time for the current
>>> stutter period to end, then we should be able to simplify the code quite=

>>> a bit and get rid of the CPU consumption entirely.  (Give or take the
>>> possible need for a given thread to check whether it was erroneously
>>> awakened early.)
>>>=20
>>> But what specifically did you have in mind?
>>=20
>> I was thinking of a 2 counter approach storing the absolute time. Use
>> an alternative counter for different stuttering sessions. But yes,
>> generally I agree with the absolute time idea. What do you think Paul?
>>=20
>> Do we want to just do  the simpler schedule_timeout at HZ / 20 to keep st=
able
>> green, and do the absolute-time approach for mainline? That might be bett=
er
>> from a process PoV. But I think stable requires patches to be upstream. G=
reg?
>>=20
>> I will try to send out patches this week to discuss this, thanks,
>=20
> Heh!!!
>=20
> Me, I was just thinking of mainline.  ;-)

Turns out it is simple enough for both mainline and stable :-).
Will test more and send it out soon.

Thanks,

- Joel


>=20
>                            Thanx, Paul