Messages in this thread | | | Subject | Re: [PATCH v3 09/10] sched/fair: use load instead of runnable load in wakeup path | From | Rik van Riel <> | Date | Mon, 07 Oct 2019 11:14:05 -0400 |
| |
On Thu, 2019-09-19 at 09:33 +0200, Vincent Guittot wrote: > runnable load has been introduced to take into account the case where > blocked load biases the wake up path which may end to select an > overloaded > CPU with a large number of runnable tasks instead of an underutilized > CPU with a huge blocked load. > > Tha wake up path now starts to looks for idle CPUs before comparing > runnable load and it's worth aligning the wake up path with the > load_balance. > > Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
On a single socket system, patches 9 & 10 have the result of driving a woken up task (when wake_wide is true) to the CPU core with the lowest blocked load, even when there is an idle core the task could run on right now.
With the whole series applied, I see a 1-2% regression in CPU use due to that issue.
With only patches 1-8 applied, I see a 1% improvement in CPU use for that same workload.
Given that it looks like select_idle_sibling and find_idlest_group_cpu do roughly the same thing, I wonder if it is enough to simply add an additional test to find_idlest_group to have it return the LLC sg, if it is called on the LLC sd on a single socket system.
That way find_idlest_group_cpu can still find an idle core like it does today.
Does that seem like a reasonable thing?
I can run tests with that :)
-- All Rights Reversed. [unhandled content-type:application/pgp-signature] | |