RE: [PATCH v3 0/3] Introduce per-task latency_nice for scheduler hints

[David Laight <David.Laight@ACULAB.COM>]

From: chris hyser <chris.hyser@oracle.com>
> Sent: 19 February 2020 17:17
> 
> On 2/19/20 6:18 AM, David Laight wrote:
> > From: chris hyser
> >> Sent: 18 February 2020 23:00
> > ...
> >> All, I was asked to take a look at the original latency_nice patchset.
> >> First, to clarify objectives, Oracle is not
> >> interested in trading throughput for latency.
> >> What we found is that the DB has specific tasks which do very little but
> >> need to do this as absolutely quickly as possible, ie extreme latency
> >> sensitivity. Second, the key to latency reduction
> >> in the task wakeup path seems to be limiting variations of "idle cpu" search.
> >> The latter particularly interests me as an example of "platform size
> >> based latency" which I believe to be important given all the varying size
> >> VMs and containers.
> >
> >  From my experiments there are a few things that seem to affect latency
> > of waking up real time (sched fifo) tasks on a normal kernel:
> 
> Sorry. I was only ever talking about sched_other as per the original patchset. I realize the term
> extreme latency
> sensitivity may have caused confusion. What that means to DB people is no doubt different than audio
> people. :-)

Shorter lines.....

ISTM you are making some already complicated code even more complex.
Better to make it simpler instead.

If you need a thread to run as soon as possible after it is woken
why not use the RT scheduler (eg SCHED_FIFO) that is what it is for.

If there are delays finding an idle cpu to migrate a process to
(especially on systems with large numbers of cpu) then that is a
general problem that can be addressed without extra knobs.

	David

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