Messages in this thread |  | | Subject | Re: [patch v4 05/18] sched: quicker balancing on fork/exec/wake | From | Peter Zijlstra <> | Date | Fri, 15 Feb 2013 14:00:53 +0100 |
| |
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.
|  |