On Wed, 2015-04-01 at 14:03 +0100, Morten Rasmussen wrote: Hi Morten,
> > Alright I see. But it is one additional wake up. And the wake up will be > > within the cluster. We will not wake up any CPU in the neighboring > > cluster unless there are tasks to be pulled. So, we can wake up a core > > out of a deep idle state and never a cluster in the problem described. > > In terms of energy efficiency, this is not so bad a scenario, is it? > > After Peter pointed out that it shouldn't happen across clusters due to > group_classify()/sg_capacity_factor() it isn't as bad as I initially > thought. It is still not an ideal solution I think. Wake-ups aren't nice > for battery-powered devices. Waking up a cpu in an already active > cluster may still imply powering up the core and bringing the L1 cache > into a usable state, but it isn't as bad as waking up a cluster. I would > prefer to avoid it if we can. Right. I still think that the patch is justified if it addresses the 10 second latency issue, but if we could find a better solution, that would be great :) > Thinking more about it, don't we also risk doing a lot of iterations in > nohz_idle_balance() leading to nothing (pure overhead) in certain corner > cases? If find_new_ild() is the last cpu in the cluster and we have one > task for each cpu in the cluster but one cpu is currently having two. > Don't we end up trying all nohz-idle cpus before giving up and balancing > the balancer cpu itself. On big machines, going through everyone could > take a while I think. No? Iterating through many CPUs could take a while, but since we only do nohz_idle_balance() when the CPU is idle and exit if need_resched, then we're only doing so if there is nothing else that needs to run. Also, we're only attempting balancing when time_after_eq rq->next_balance, so much of the time, we don't actually traverse all the CPUs. So this may not be too big of an issue. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
