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

[Steven Rostedt <rostedt@goodmis.org>]

On Mon, 10 Feb 2025 09:07:27 -0500
Joel Fernandes <joel@joelfernandes.org> wrote:

> On Thu, Feb 6, 2025 at 8:30 AM Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > On Wed, 5 Feb 2025 22:07:12 -0500
> > Joel Fernandes <joel@joelfernandes.org> wrote:  
> > > >
> > > > 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...  
> >
> > But it would have to guarantee that the RR it is delaying is of the same
> > priority, and that delaying the DL is not going to cause something to miss
> > its deadline.  
> 
> See Peter comment: "Then pick another number; RT too has a max
> scheduling latency number (on some random hardware). If you stay below
> that, all is fine.".

See mine and Sebastion's reply. Just adding another interrupt turn around,
and you already lost.


> > You see, LAZY was *created* for this purpose. Of letting the scheduler know
> > that the running task is in a critical section and the timer tick should
> > not preempt a SCHED_OTHER task.
> > I just wanted to extend this to SCHED_OTHER in user space too.  
> 
> Currently it does not "let anyone know" it is running in a critical
> section though. Various paths (update_curr(), wake up) just do a
> 'lazy' resched until the timer tick has elapsed, or the task returns
> to usermode/idle at which point schedule() is called. And it does this
> only for FAIR tasks. That can well happen even if the currently
> running task is not in a critical section in the kernel at all. Sure,
> it may benefit critical sections in the upstream kernel but where is
> that explicit?  I still feel we should not overload this in-kernel
> mechanism for userspace locking and complicate things.

That's nice that you don't feel it. But I do. ;-)

> 
> > > 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.  
> >
> > Just using RT policy to improve performance is not an RT project. I'm
> > talking about projects that if you miss a deadline things crash. Where the
> > project works very hard to make sure everything works as intended.  
> 
> No no no, I have done way more than applying just the RT policy. So
> that means you do not know me that well;-).. I have worked on audio
> driver latency, low latency audio, latency issues in vmalloc code,
> preempt tracers, irq tracepoints , wake up latency tracers and various
> scheduler overhead debug — many of those issues dealt with sub
> millisecond latency.. I also dealt with cpu idle issues in the
> hardware causing real time latency problems (see my past talks if
> interested).  I was partly a hardware engineer when I started my
> career and have built circuits. I have Electronics and Computer
> engineering degrees.

None of that sounds to me like an RT project. I'm talking about robotics,
industrial machines, autonomous driving, power plants, etc. Where
everything is measured in WCET.

-- Steve