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

[David Laight <david.laight.linux@gmail.com>]

On Mon, 10 Feb 2025 14:43:21 -0500
Steven Rostedt <rostedt@goodmis.org> wrote:

> On Thu, 6 Feb 2025 14:44:08 +0100
> Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
> 
> > I did add a scheduling point in rt_spin_unlock() if LAZY was set and
> > based on few tests it was something between noise and worse. It seems
> > that "run to completion" is better than interrupt the kernel in the
> > middle whatever it is doing. "Don't preempt the lock owner" is already
> > handled by LAZY with the scheduling point on return to userland.  
> 
> Does that mean that PREEMPT_RT requires a non preempt method for
> SCHED_OTHER for SCHED_OTHER to not hit the issues that we were originally
> hitting? That is, with being able to preempt spin_locks in PREEMPT_RT,
> running a system with PREEMPT_RT in full preemption mode will still suffer
> performance issues against a non PREEMPT_RT running in full preemption mode?

My 'gut feel' is that all the context switches with PREEMPT_RT add a significant
overhead.
It might not matter if your system is lightly loaded (overspecified),
but if you need to run at 95%+ cpu then they will hit you hard.

Maybe you can afford to drop softint and napi code to a high(ish) priority
thread, but I'd have thought that most interrupts should stay that way and
most spinlocks stay as spinlocks - and probably all disable interrupts!
Any interrupts that take 'a long time' or spinlocks that are held for 'a long time'
really need changing anyway.

But there are some really dreadful bits of code in the kernel.
One of the Intel ethernet drivers spins for ages whenever the bios is accessing
the hardware - you can't run RTP audio tests on that system.

Perhaps interrupt disable and pre-emption times should (optionally) be monitored
and a warning output every time they go up significantly.
A 'name and shame' policy might improve matters.

	David

> 
> -- Steve
>