Re: commit e9e9250b: sync wakeup bustage when waker is an RT task

Mike Galbraith
2010-05-17T09:04:36Z

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