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.
pgppVg4NlC9J_.pgp
Description: PGP signature
