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

On Mon, 10 Feb 2025 09:07:27 -0500
Joel Fernandes [off-list ref] wrote:

On Thu, Feb 6, 2025 at 8:30 AM Steven Rostedt [off-list ref] wrote:

quoted

On Wed, 5 Feb 2025 22:07:12 -0500
Joel Fernandes [off-list ref] wrote:  

quoted

quoted

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.

quoted

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. ;-)

quoted

quoted

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