Re: [RFC][PATCH 1/2] sched: Extended scheduler time slice

On Wed, Feb 5, 2025 at 8:16 AM Steven Rostedt [off-list ref] wrote:
[...]

quoted

quoted

And you are also OK with allowing any task to make an RT task wait longer?

Putting my RT hat back on, I would definitely disable that on any system
that requires RT.

Just so I understand, you are basically saying that you want this
feature only for FAIR tasks, and allowing RT tasks to extend time
slice might actually hurt the latency of (other) RT tasks on the
system right? This assumes PREEMPT_RT because the latency is 50us
right?

RT tasks don't have a time slice. They are affected by events. An external
interrupt coming in, or a timer going off that states something is
happening. Perhaps we could use this for SCHED_RR or maybe even
SCHED_DEADLINE, as those do have time slices.

But if it does get used, it should only be used when the task being
scheduled is the same SCHED_RR priority, or if SCHED_DEADLINE will not fail
its guarantees.

Right, it would apply still to RR/DL though...

quoted

In any case, if you want this to only work on FAIR tasks and not RT
tasks, why is that only possible to do with rseq() + LAZY preemption
and not Prakash's new API + all preemption modes?

Also you can just ignore RT tasks (not that I'm saying that's a good
idea but..) in taskshrd_delay_resched() in that patch if you ever
wanted to do that.

I just feel the RT latency thing is a non-issue AFAICS.

Have you worked on any RT projects before?

Heh.. I think maybe you misunderstood my statement, I was mentioning
that I felt (similar to Peter I think) that NOT adopting this feature
generically for all tasks due to a concern of 50us latency maybe does
not make sense since poorly designed app / random hardware already
have this issue. I think the main concern discussed in this thread is
(and please CMIIW):
1. Locking down this feature to only SCHED_OTHER versus making it
generic (maybe sched_ext could also use it?).
2. Tying it to specific preemption methods which may change user mode
behavior/expectation (because LAZY is tied to preemption method).
3. Overloading the purpose of LAZY: My understanding is, the purpose
of LAZY is to let the scheduler decide if it wants to preempt based on
preemption mode. It is not based on any hint, just on the preemption
mode. I guess you are overloading LAZY by making LAZY flag also extend
userspace timeslice (versus say making the time-slice extension hint
its own thing...).

Yes, I have worked on RT projects before --  you would know better
than anyone. :-D. But admittedly, I haven't got to work much with
PREEMPT_RT systems.

 - Joel