On Thu, 2013-02-14 at 13:42 +0530, Preeti U Murthy wrote: > Hi Peter,Alex, > If the eligible cpus happen to be all the cpus,then iterating over all > the > cpus for idlest would be much worse than iterating over sched domains > right?
Depends, doing a domain walk generally gets you 2n cpus visited -- geometric series and such. A simple scan of the top-most domain mask that's eligible will limit that to n. > I am also wondering how important it is to bias the balancing of > forked/woken up > task onto an idlest cpu at every iteration. Yeah, I don't know, it seems overkill to me, that code is from before my time, so far it has survived. > If biasing towards the idlest_cpu at every iteration is not really the > criteria, > then we could cut down on the iterations in fork/exec/wake balancing. > Then the problem boils down to,is the option between biasing our > search towards > the idlest_cpu or the idlest_group.If we are not really concerned > about balancing > load across groups,but ensuring we find the idlest cpu to run the > task on,then > Alex's patch seems to have covered the criteria. > > However if the concern is to distribute the load uniformly across > groups,then > I have the following patch which might reduce the overhead of the > search of an > eligible cpu for a forked/exec/woken up task. Nah, so I think the whole bias thing was mostly done to avoid over-balancing and possibly to compensate for some approximations on the whole weight/load measurement stuff. -- 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/