| Date | Sat, 15 Aug 2015 15:05:45 +0200 | From | Peter Zijlstra <> | Subject | Re: [RFCv5 PATCH 38/46] sched: scheduler-driven cpu frequency selection |
| |
On Tue, Jul 07, 2015 at 07:24:21PM +0100, Morten Rasmussen wrote: > +void cpufreq_sched_set_cap(int cpu, unsigned long capacity) > +{ > + unsigned int freq_new, cpu_tmp; > + struct cpufreq_policy *policy; > + struct gov_data *gd; > + unsigned long capacity_max = 0; > + > + /* update per-cpu capacity request */ > + __this_cpu_write(pcpu_capacity, capacity); > + > + policy = cpufreq_cpu_get(cpu); > + if (IS_ERR_OR_NULL(policy)) { > + return; > + } > + > + if (!policy->governor_data) > + goto out; > + > + gd = policy->governor_data; > + > + /* bail early if we are throttled */ > + if (ktime_before(ktime_get(), gd->throttle)) > + goto out;
Isn't this the wrong place to throttle? Suppose you're getting multiple new tasks placed on this CPU, the first one would trigger this callback and start increasing freq..
While we're still changing freq. (and therefore throttled), another task comes in which would again raise the freq.
With this scheme you loose the latter freq. change and will not re-evaluate.
Any scheme that limits the callbacks to the actual hardware will have to buffer requests and once the hardware returns (be it through an interrupt or timeout) issue the latest request.
|