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]
Date:	Mon, 14 Jul 2014 18:22:49 +0200
From:	Peter Zijlstra <>
To:	Morten Rasmussen <>
Cc:	Vincent Guittot <>,
	Ingo Molnar <>,
	linux-kernel <>,
	Russell King - ARM Linux <>,
	LAK <>,
	Preeti U Murthy <>,
	Mike Galbraith <>,
	Nicolas Pitre <>,
	"" <>,
	Daniel Lezcano <>,
	Dietmar Eggemann <>
Subject: Re: [PATCH v3 09/12] Revert "sched: Put rq's sched_avg under

On Mon, Jul 14, 2014 at 03:04:35PM +0100, Morten Rasmussen wrote:
> > I'm struggling to fully grasp your intent. We need DVFS like accounting
> > for sure, and that means a current freq hook, but I'm not entirely sure
> > how that relates to capacity.
> We can abstract all the factors that affect current compute capacity
> (frequency, P-states, big.LITTLE,...) in the scheduler by having
> something like capacity_{cur,avail} to tell us how much capacity does a
> particular cpu have in its current state. Assuming that implement scale
> invariance for entity load tracking (we are working on that), we can
> directly compare task utilization with compute capacity for balancing
> decisions. For example, we can figure out how much spare capacity a cpu
> has in its current state by simply:
> spare_capacity(cpu) = capacity_avail(cpu) - \sum_{tasks(cpu)}^{t} util(t)
> If you put more than spare_capacity(cpu) worth of task utilization on
> the cpu, you will cause the cpu (and any affected cpus) to change
> P-state and potentially be less energy-efficient.
> Does that make any sense?
> Instead of dealing with frequencies directly in the scheduler code, we
> can abstract it by just having scalable compute capacity.

Ah, ok. Same thing then.

> > But yes, for application the tipping point is u == 1, up until that
> > point pure utilization makes sense, after that our runnable_avg makes
> > more sense.
> Agreed.
> If you really care about latency/performance you might be interested in
> comparing running_avg and runnable_avg even for u < 1. If the
> running_avg/runnable_avg ratio is significantly less than one, tasks are
> waiting on the rq to be scheduled.

Indeed, that gives a measure of queueing.

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists