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

[Joel Fernandes]

On Wed, Feb 5, 2025 at 8:16 AM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
[...]
> >
> > > 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...

> > 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