RE: sched/fair: scheduler not running high priority process on idle cpu

From: David Laight
Date: Wed Jan 15 2020 - 10:10:01 EST


From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> Sent: 15 January 2020 14:57
> On Wed, Jan 15, 2020 at 12:44:19PM +0000, David Laight wrote:
>
> > Code that runs with a spin-lock held (or otherwise disables preemption)
> > for significant periods probably ought to be detected and warned.
> > I'm not sure of a suitable limit, 100us is probably excessive on x86.
>
> Problem is, without CONFIG_PREEMPT_COUNT (basically only
> PREEMPT/PREEMPT_RT) we can't even tell.
>
> And I think we tried adding warnings to things like softirq, but then we
> get into arguments with the pure performance people on how allowing it
> longer will make their benchmarks go faster.

The interval would have to be a sysctl - like the one for sleeping uninterruptibly.
(Although that one is a pain for some kernel threads. I'd like to be able to
mark some uninterruptible sleeps as 'long term' and also not affecting the load
average.)

I remember (a long time ago) adding code to an ethernet driver to limit it
to 90% of the bandwidth to allow other systems to transmit (10M HDX).
Someone said ' we can't do that, people expect 100%', a week later he
asked me how to enable it because the AMD Lance could never transmit
if receiving back to back packets (eg in promiscuous mode).
Benchmarks are a PITA....

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)