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

[Joel Fernandes <joel@joelfernandes.org>]

On Tue, Feb 4, 2025 at 10:03 PM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Tue, 4 Feb 2025 19:56:09 -0500
> Joel Fernandes <joel@joelfernandes.org> wrote:
>
> > > Here is the RFC I had sent that Peter is referring
> >
> > FWIW, I second the idea of a new syscall for this than (ab)using rseq
> > and also independence from preemption method. I agree that something
> > generic is better than relying on preemption method.
>
> So you are for adding another user/kernel memory mapped section?

I don't personally mind that.

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

But in a poorly designed system, if you have RT tasks at higher
priority that preempt things lower in RT, that would already cause
latency anyway. Similarly, I would also consider any PREEMPT_RT system
that (mis)uses this API in an RT task as also a poorly designed
system. I think PREEMPT_RT systems generally require careful design
anyway.  So the fact that a system is poorly designed and thus causes
latency is not the kernel's problem IMO.

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.

thanks,

 - Joel