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.
> 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.
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.
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.
> Suggested-by: Uladzislau Rezki (Sony) <[email protected]>
> Signed-off-by: Zqiang <[email protected]>
Sebastian
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) <[email protected]>
> Signed-off-by: Zqiang <[email protected]>
>Sebastian