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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1274087070.17267.37.camel@marge.simson.net>
Date:	Mon, 17 May 2010 11:04:30 +0200
From:	Mike Galbraith <efault@....de>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Ingo Molnar <mingo@...e.hu>, LKML <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: commit e9e9250b: sync wakeup bustage when waker is an RT task

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/