RE: [PATCH v2 0/7] Add latency_nice priority

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

From: Vincent Guittot
> Sent: 12 May 2022 17:35
> 
> This patchset restarts the work about adding a latency nice priority to
> describe the latency tolerance of cfs tasks.
> 
> The patches [1-4] have been done by Parth:
> https://lore.kernel.org/lkml/20200228090755.22829-1-parth@linux.ibm.com/
> 
> I have just rebased and moved the set of latency priority outside the
> priority update. I have removed the reviewed tag because the patches
> are 2 years old.
> 
> The patches [5-7] use latency nice priority to decide if a cfs task can
> preempt the current running task. Patch 5 gives some tests results with
> cyclictests and hackbench to highlight the benefit of latency nice
> priority for short interactive task or long intensive tasks.

I'd have thought the best way to reduce latency would be to look
harder for an idle cpu before trying to preempt the current task.

By far the worst case latency for a cfs task is waking it from an
rt task.
AFAICT the cpu selection algorithm is something like:
1) if the cpu it last ran on is idle, schedule it there.
2) if one of a small subset of cpu is idle run it there.
3) schedule on the current cpu after the rt thread exits.

Then there is the additional behaviour:
An rt thread (almost) always starts on the cpu it ran on last,
any running cfs thread is put on the q for that cpu.

This makes it very difficult to start a background cfs thread
from an active rt thread.
Quite often it won't migrate to an idle cpu until the timer
tick scheduler rebalance happens.

I think the search for an idle cpu is also limited when woken
by a cfs thread.

	David

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