Messages in this thread | | | Subject | Re: [RFC PATCH v3 4/6] sched/cpufreq: Introduce sugov_cpu_ramp_boost | From | Douglas Raillard <> | Date | Mon, 14 Oct 2019 16:32:11 +0100 |
| |
Hi Peter,
On 10/14/19 3:33 PM, Peter Zijlstra wrote: > On Fri, Oct 11, 2019 at 02:44:58PM +0100, Douglas RAILLARD wrote: >> Use the utilization signals dynamic to detect when the utilization of a >> set of tasks starts increasing because of a change in tasks' behavior. >> This allows detecting when spending extra power for faster frequency >> ramp up response would be beneficial to the reactivity of the system. >> >> This ramp boost is computed as the difference >> util_avg-util_est_enqueued. This number somehow represents a lower bound > > That reads funny, maybe 'as the difference between util_avg and > util_est_enqueued' ?
Indeed, it was not clear that it was a formula. Talking about formulas, I remember laying down the relations between the various flavors of util signals in the v2 thread. This could be turned rather easily into a doc page for PELT, along with a signal-processing-friendly accurate description of how the PELT signals are built. Would such a patch be of any interest the kernel tree ?
>> of how much extra utilization this tasks is actually using, compared to >> our best current stable knowledge of it (which is util_est_enqueued). >> >> When the set of runnable tasks changes, the boost is disabled as the >> impact of blocked utilization on util_avg will make the delta with >> util_est_enqueued not very informative. > >> @@ -561,6 +604,7 @@ static unsigned int sugov_next_freq_shared(struct sugov_cpu *sg_cpu, u64 time) >> } >> } >> >> + >> return get_next_freq(sg_policy, util, max); >> } > > Surely we can do without this extra whitespace? :-) > woops ...
Cheers, Douglas
| |