Messages in this thread | | | Subject | Re: commit e9e9250b: sync wakeup bustage when waker is an RT task | From | Mike Galbraith <> | Date | Mon, 17 May 2010 11:04:30 +0200 |
| |
On Mon, 2010-05-17 at 10:49 +0200, Peter Zijlstra wrote: > On Mon, 2010-05-17 at 06:38 +0200, Mike Galbraith wrote: > > What would be the harm/consequence of restoring RT tasks to rq->load so > > the wake_affine()::sync logic just worked as before without hackery? > > Well, you'd have to constantly adjust the task weight of RT tasks to > reflect their actual consumption. Not really feasible.
Egad, forget that.
> So the proportional stuff works like: > > slice_i = w_i / (\Sum_j w_j) * dt > > Giving a RT task a sensible weight we'd have to reverse that: > > w_i = slice_i/dt * (\Sum_j w_j) > > which is something that depends on the rq->load, so every time you > change the rq->load you'd have to recompute the weight of all the RT > tasks, which again changes the rq->load (got a head-ache already? :-)
Yup.
> > The weight is a more or less random number, but looking around, with > > them excluded, avg_load_per_task is lowered when RT tasks enter the > > system, and rq->load[] misses their weight. (Dunno what effect it has > > on tg shares). > > Well, those things are more or less a 'good' thing, it makes it purely > about sched_fair.
(Yeah, I was pondering up/down sides)
> So the thing to do I think is to teach wake_affine about cpu_power, > because that is what includes the RT tasks. > > The proper comparison of rq weights (like the regular load balancer > already does) is: > > A->load / A->cpu_power ~ B->load / B->cpu_power > > The lower the cpu_power of a particular cpu, the less processing > capacity it has, the smaller its share of the total weight should be to > provide equal work for each task.
Hm, sounds kinda heavy/complicated for fast-path. I think I like little hack better than trying to teach it about cpu_power :)
-Mike
| |