linux-kernel - RE: [PATCH v3] rcu: Only boost rcu reader tasks with lower priority than boost kthreads

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 12 Mar 2022 02:57:24 +0000
From:   "Zhang, Qiang1" <qiang1.zhang@...el.com>
To:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>
CC:     "paulmck@...nel.org" <paulmck@...nel.org>,
        "frederic@...nel.org" <frederic@...nel.org>,
        "urezki@...il.com" <urezki@...il.com>,
        "quic_neeraju@...cinc.com" <quic_neeraju@...cinc.com>,
        "josh@...htriplett.org" <josh@...htriplett.org>,
        "juri.lelli@...hat.com" <juri.lelli@...hat.com>,
        "rcu@...r.kernel.org" <rcu@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v3] rcu: Only boost rcu reader tasks with lower priority
 than boost kthreads

On 2022-03-11 10:22:26 [+0800], Zqiang wrote:
> When RCU_BOOST is enabled, the boost kthreads will boosting readers
> who are blocking a given grace period, if the current reader tasks
                                       ^ Period.

> have a higher priority than boost kthreads(the boost kthreads priority
> not always 1, if the kthread_prio is set), 

>>This confuses me:
>>- Why does this matter
>>- If it is not RT prio, what is then? Higher or lower? Afaik it is
>>  always >= 1.

If it is not RT prio, the sanitize_kthread_prio() will limit RT prio

> boosting is useless, skip
> current task and select next task to boosting, reduce the time for a
> given grace period.

>>So if the task, that is stuck in a rcu_read() section, has a higher
>>priority than the boosting thread then boosting is futile. Understood.
>>
>>Please correct me if I'm wrong but this is intended for !SCHED_OTHER
>>tasks since there shouldn't a be PI chain on boost_mtx so that its
>>default RT priority is boosted above what has been configured.

Yes, you are right. If the boosting task which itself already boosted due to PI chain,
and Its priority may only be temporarily higher than boost kthreads,  once that
PI boost is lifted the task may still be in a RCU section, but if we have been skipped it,
this task have been missed the opportunity to be boosted.

>>
>>You skip boosting tasks which are itself already boosted due to a PI
>>chain. Once that PI boost is lifted the task may still be in a RCU
>>section. But if I understand you right, your intention is skip boosting
>>tasks with a higher priority and concentrate and those which are in
>>need. This shouldn't make a difference unless the scheduler is able to
>>move the rcu-boosted task to another CPU.
>>

Yes, It make sense when the rcu-boosted kthreads and task which to be boosting
should run  difference CPU .

>>Am I right so far? If so this should be part of the commit message (the
>>intention and the result). Also, please add that part with
>>boost_exp_tasks. The comment above boost_mtx is now above
>>boost_exp_tasks with a space so it looks (at least to me) like these two
>>don't belong together.

Yes, I will add your description to the commit  information.


> Suggested-by: Uladzislau Rezki (Sony) <urezki@...il.com>
> Signed-off-by: Zqiang <qiang1.zhang@...el.com>

>Sebastian