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

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2025-02-06 14:57:44 [+0100], Peter Zijlstra wrote:
> On Thu, Feb 06, 2025 at 02:53:53PM +0100, Sebastian Andrzej Siewior wrote:
> > On 2025-02-06 14:48:59 [+0100], Peter Zijlstra wrote:
> > > On Thu, Feb 06, 2025 at 02:44:08PM +0100, Sebastian Andrzej Siewior wrote:
> > > > SCHED_OTHER vs SCHED_OTHER after all. But please don't delay a wakeup of
> > > > SCHED_FIFO/ RR/ DL because of this LAZY hint.
> > > 
> > > Thing will get delayed if interrupts are disabled or kernel has
> > > preemption disabled too. So as long as we ensure hint crap is of equal
> > > order, nothing cares if you do.
> > > 
> > > If you can't tell the difference between task does hint crap in
> > > userspace and task is in the middle of syscall, you can't tell the
> > > difference.
> > 
> > I can tell the difference if I see a trace where an interrupt fires,
> > performs a wakeup and the SCHED_OTHER task remains on CPU while the task
> > SCHED_FIFO task sits on the runqueue until a timer fires.
> 
> Right, but so what? Same delay will happen if interrupt fires in the
> middle of a preempt_disable() region.

But I do see an interrupt and a wakeup in the middle of a
preempt-disable section based on the preempt-counter. Then once the
preempt-disabled section is done, sched-switch is expected.

> Or if interrupt gets pending while interrupts are disabled, except your
> trace will not show that.

That is true. In general we try not to have a lot of these. Also pushing
the "unexpected" part of the CPU such as unrelated interrupts. So may
end up a RT thread and SCHED_OTHER threads on the same CPU. It would be
very unfortunate if this "let me give a bit extra time so I get out of
my critical section" within this SCHED_OTHER application affects the RT
application.
You run SCHED_OTHER tasks and a cyclic interrupt wakes your RT task
every ms. You expect to be scheduled asap, so ideally 0us but 70us in
real world. Then this feature adds 20us on top?

> Your worst case response time isn't affected. That's all that matters.

Sebastian