lkml.org 
[lkml]   [2020]   [Jan]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 1/3] sched/fair: Add asymmetric CPU capacity wakeup scan
On Friday 24 Jan 2020 at 14:14:47 (+0000), Valentin Schneider wrote:
> If we fail to find a big enough CPU, we'll just fallback to the rest of
> select_idle_sibling() which will pick an idle CPU, just without caring
> about capacity.
>
> Now an alternative here would be to:
> - return the first idle CPU on which the task fits (what the above does)
> - else, return the biggest idle CPU we found (this could e.g. still steer
> the task towards a medium on a tri-capacity system)

Sounds reasonable to me.

> I think what we were trying to go with here is to not entirely hijack
> select_idle_sibling(). If we go with the above alternative, topologies
> with sched_asym_cpucapacity enabled would only ever see
> select_idle_capacity() and not the rest of select_idle_sibling(). Not sure
> if it's a bad thing or not, but it's something to ponder over.

Right, I would think your suggestion above is a pretty sensible policy
for asymmetric systems, and I don't think the rest of
select_idle_sibling() will do a much better job on such systems at
finding an idle CPU than select_idle_capacity() would do, but I see
your point.

Now, not having to re-iterate over the CPUs again might keep the wakeup
latency a bit lower -- perhaps something noticeable with hackbench ?
Worth a try.

In any case, no strong opinion. With that missing call to
sync_entity_load_avg() fixed, the patch looks pretty decent to me.

Thanks,
Quentin

\
 
 \ /
  Last update: 2020-01-24 16:13    [W:0.034 / U:1.560 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site