Messages in this thread | | | Date | Wed, 30 Oct 2019 13:29:20 -0400 | From | Phil Auld <> | Subject | Re: [PATCH v4 00/10] sched/fair: rework the CFS load balance |
| |
On Wed, Oct 30, 2019 at 06:25:09PM +0100 Valentin Schneider wrote: > On 30/10/2019 18:19, Phil Auld wrote: > >> Well from the code nobody but us (asymmetric capacity systems) set > >> SD_BALANCE_WAKE. I was however curious if there were some folks who set it > >> with out of tree code for some reason. > >> > >> As Dietmar said, not having SD_BALANCE_WAKE means you'll never go through > >> the slow path on wakeups, because there is no domain with SD_BALANCE_WAKE for > >> the domain loop to find. Depending on your topology you most likely will > >> go through it on fork or exec though. > >> > >> IOW wake_wide() is not really widening the wakeup scan on wakeups using > >> mainline topology code (disregarding asymmetric capacity systems), which > >> sounds a bit... off. > > > > Thanks. It's not currently set. I'll set it and re-run to see if it makes > > a difference. > > > > Note that it might do more harm than good, it's not set in the default > topology because it's too aggressive, see > > 182a85f8a119 ("sched: Disable wakeup balancing") >
Heh, yeah... even as it's running I can see that this killing it :)
> > > > However, I'm not sure why it would be making a difference for only the cgroup > > case. If this is causing issues I'd expect it to effect both runs. > > > > In general I think these threads want to wake up the last cpu they were on. > > And given there are fewer cpu bound tasks that CPUs that wake cpu should, > > more often than not, be idle. > > > > > > Cheers, > > Phil > > > > > >
--
| |