OSDN Git Service

sched/rt: cpupri_find: Trigger a full search as fallback
authorQais Yousef <qais.yousef@arm.com>
Thu, 5 Mar 2020 10:24:50 +0000 (10:24 +0000)
committerPeter Zijlstra <peterz@infradead.org>
Fri, 20 Mar 2020 12:06:20 +0000 (13:06 +0100)
commite94f80f6c49020008e6fa0f3d4b806b8595d17d8
treeca6a4acf15134ed1f12a178a3a8661d145c3f222
parent26c7295be0c5e6da3fa45970e9748be983175b1b
sched/rt: cpupri_find: Trigger a full search as fallback

If we failed to find a fitting CPU, in cpupri_find(), we only fallback
to the level we found a hit at.

But Steve suggested to fallback to a second full scan instead as this
could be a better effort.

https://lore.kernel.org/lkml/20200304135404.146c56eb@gandalf.local.home/

We trigger the 2nd search unconditionally since the argument about
triggering a full search is that the recorded fall back level might have
become empty by then. Which means storing any data about what happened
would be meaningless and stale.

I had a humble try at timing it and it seemed okay for the small 6 CPUs
system I was running on

https://lore.kernel.org/lkml/20200305124324.42x6ehjxbnjkklnh@e107158-lin.cambridge.arm.com/

On large system this second full scan could be expensive. But there are
no users outside capacity awareness for this fitness function at the
moment. Heterogeneous systems tend to be small with 8cores in total.

Suggested-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Qais Yousef <qais.yousef@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Link: https://lkml.kernel.org/r/20200310142219.syxzn5ljpdxqtbgx@e107158-lin.cambridge.arm.com
kernel/sched/cpupri.c