From: chris hyser <chris.hyser@xxxxxxxxxx>
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
sensitivity may have caused confusion. What that means to DB people is no doubt different than audio
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.