Messages in this thread | | | Date | Fri, 24 Jan 2020 15:11:34 +0000 | From | Quentin Perret <> | Subject | Re: [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
| |