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

[David Laight]

I've a test that uses four RT priority processes to process audio data every 10ms.
One process wakes up the other three, they all 'beaver away' clearing a queue of
jobs and the last one to finish sleeps until the next tick.
Usually this takes about 0.5ms, but sometimes takes over 3ms.

AFAICT the processes are normally woken on the same cpu they last ran on.
There seems to be a problem when the selected cpu is running a (low priority)
process that is looping in kernel [1].
I'd expect my process to be picked up by one of the idle cpus, but this
doesn't happen.
Instead the process sits in state 'waiting' until the active processes sleeps
(or calls cond_resched()).

Is this really the expected behaviour?????

This is  5.4.0-rc7 kernel.
I could try the current 5.5-rc one if any recent changes might affect things.

Additionally (probably because cv_wait() is implemented with 'ticket locks')
none of the other processes waiting for the cv are woken either.

[1] Xorg seems to periodically request the kernel workqueue run
drm_cflush_sg() to flush the display buffer cache.
For a 2560x1140 display this is 3600 4k pages and the flush loop
takes ~3.3ms.
However there are probably other places where a process can run in
kernel for significant lengths of time.

	David

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