[v2] hrtimer: More fixes for handling of timer slack of rt tasks

[PATCH v2 0/1] hrtimer: More fixes for handling of timer slack of rt tasks

Posted by Felix Moessbauer 1 year, 4 months ago

This series fixes the (hopefully) last location of an incorrectly
handled timer slack on rt tasks in hrtimer_start_range_ns(), which was
uncovered by a userland change in glibc 2.33.

Changes since v1:

- drop patch "hrtimer: Document, that PI boosted tasks have no timer slack", as
  this behavior is incorrect and is already adressed in 20240610192018.1567075-1-qyousef@layalina.io
- use task_is_realtime() instead of rt_task()
- fix style of commit message

v1 discussion: https://lore.kernel.org/lkml/20240805124116.21394-1-felix.moessbauer@siemens.com

Best regards,
Felix Moessbauer
Siemens AG

Felix Moessbauer (1):
  hrtimer: Ignore slack time for RT tasks in hrtimer_start_range_ns()

 kernel/time/hrtimer.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

-- 
2.39.2

Re: [PATCH v2 0/1] hrtimer: More fixes for handling of timer slack of rt tasks

Posted by Qais Yousef 1 year, 4 months ago

On 08/05/24 16:09, Felix Moessbauer wrote:
> This series fixes the (hopefully) last location of an incorrectly
> handled timer slack on rt tasks in hrtimer_start_range_ns(), which was
> uncovered by a userland change in glibc 2.33.
> 
> Changes since v1:
> 
> - drop patch "hrtimer: Document, that PI boosted tasks have no timer slack", as
>   this behavior is incorrect and is already adressed in 20240610192018.1567075-1-qyousef@layalina.io

There was discussion about this hrtimer usage in earlier version if it helps to
come up with a potentially better patch

	https://lore.kernel.org/lkml/20240521110035.KRIwllGe@linutronix.de/

My patches got picked up by the way, you'd probably want to rebase and resend
as now the function is named rt_or_dl_task_policy()


Cheers

--
Qais Yousef

> - use task_is_realtime() instead of rt_task()
> - fix style of commit message
> 
> v1 discussion: https://lore.kernel.org/lkml/20240805124116.21394-1-felix.moessbauer@siemens.com
> 
> Best regards,
> Felix Moessbauer
> Siemens AG
> 
> Felix Moessbauer (1):
>   hrtimer: Ignore slack time for RT tasks in hrtimer_start_range_ns()
> 
>  kernel/time/hrtimer.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> -- 
> 2.39.2
>

Re: [PATCH v2 0/1] hrtimer: More fixes for handling of timer slack of rt tasks

Posted by MOESSBAUER, Felix 1 year, 4 months ago

On Fri, 2024-08-09 at 02:34 +0100, Qais Yousef wrote:
> On 08/05/24 16:09, Felix Moessbauer wrote:
> > This series fixes the (hopefully) last location of an incorrectly
> > handled timer slack on rt tasks in hrtimer_start_range_ns(), which
> > was
> > uncovered by a userland change in glibc 2.33.
> > 
> > Changes since v1:
> > 
> > - drop patch "hrtimer: Document, that PI boosted tasks have no
> > timer slack", as
> >   this behavior is incorrect and is already adressed in
> > 20240610192018.1567075-1-qyousef@layalina.io
> 
> There was discussion about this hrtimer usage in earlier version if
> it helps to
> come up with a potentially better patch

Hi, Sebastian already pointed me to this thread.

When debugging my issue, I did not know about it but was scratching my
head if the behavior / usage of rt_task is actually correct.
The whole naming was quite confusing. Many thanks for cleaning that up.

> 
>         
> https://lore.kernel.org/lkml/20240521110035.KRIwllGe@linutronix.de/
> 
> My patches got picked up by the way, you'd probably want to rebase
> and resend
> as now the function is named rt_or_dl_task_policy()

As we use rt_or_dl_task() in nanosleep, I'm wondering if we should use
the same in hrtimer_start_range_ns(). Is that because PI boosted tasks
need to acquire a lock which can only be a mutex_t or equivalent
sleeping lock on PREEMPT_RT?

Anyways, I'm thinking about getting rid of the policy based delta=0 and
just set the task->timer_slack_ns to 0 when changing the scheduling
policy (and changing it back to the default when reverting to
SCHED_OTHER). By that, we can get rid of the special handling and users
of the procfs would also see correct data in /timerslack_ns.

Felix

> 
> 
> Cheers
> 
> --
> Qais Yousef
> 
> > - use task_is_realtime() instead of rt_task()
> > - fix style of commit message
> > 
> > v1 discussion:
> > https://lore.kernel.org/lkml/20240805124116.21394-1-felix.moessbauer@siemens.com
> > 
> > Best regards,
> > Felix Moessbauer
> > Siemens AG
> > 
> > Felix Moessbauer (1):
> >   hrtimer: Ignore slack time for RT tasks in
> > hrtimer_start_range_ns()
> > 
> >  kernel/time/hrtimer.c | 6 +++++-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > -- 
> > 2.39.2
> > 

-- 
Siemens AG, Technology
Linux Expert Center

Re: [PATCH v2 0/1] hrtimer: More fixes for handling of timer slack of rt tasks

Posted by Thomas Gleixner 1 year, 4 months ago

On Fri, Aug 09 2024 at 08:47, Felix MOESSBAUER wrote:
> On Fri, 2024-08-09 at 02:34 +0100, Qais Yousef wrote:
>> On 08/05/24 16:09, Felix Moessbauer wrote:
>> > This series fixes the (hopefully) last location of an incorrectly
>> > handled timer slack on rt tasks in hrtimer_start_range_ns(), which
>> > was
>> > uncovered by a userland change in glibc 2.33.
>> > 
>> > Changes since v1:
>> > 
>> > - drop patch "hrtimer: Document, that PI boosted tasks have no
>> > timer slack", as
>> >   this behavior is incorrect and is already adressed in
>> > 20240610192018.1567075-1-qyousef@layalina.io
>> 
>> There was discussion about this hrtimer usage in earlier version if
>> it helps to
>> come up with a potentially better patch
>
> Hi, Sebastian already pointed me to this thread.
>
> When debugging my issue, I did not know about it but was scratching my
> head if the behavior / usage of rt_task is actually correct.
> The whole naming was quite confusing. Many thanks for cleaning that up.
>
>> 
>>         
>> https://lore.kernel.org/lkml/20240521110035.KRIwllGe@linutronix.de/
>> 
>> My patches got picked up by the way, you'd probably want to rebase
>> and resend
>> as now the function is named rt_or_dl_task_policy()
>
> As we use rt_or_dl_task() in nanosleep, I'm wondering if we should use
> the same in hrtimer_start_range_ns(). Is that because PI boosted tasks
> need to acquire a lock which can only be a mutex_t or equivalent
> sleeping lock on PREEMPT_RT?

No. Arming the timer has nothing to do with mutexes or such. It's an
optimization to grant RT/DL tasks zero slack automatically.

The correct thing is to use policy based delta adjustment.

The fact that a task got boosted temporatily does not make it eligble
for zero slack. It stays a SCHED_OTHER task no matter what.

rt_or_dl_task() in nanosleep() is fundamentally wrong and needs to be
replaced with rt_or_dl_task_policy() and not the other way round.

> Anyways, I'm thinking about getting rid of the policy based delta=0 and
> just set the task->timer_slack_ns to 0 when changing the scheduling
> policy (and changing it back to the default when reverting to
> SCHED_OTHER). By that, we can get rid of the special handling and users
> of the procfs would also see correct data in /timerslack_ns.

That makes sense.

Thanks

        tglx