On Mon, Nov 21, 2016 at 04:24:24PM +0000, Patrick Bellasi wrote: > On 21-Nov 16:26, Peter Zijlstra wrote:
> > In any case, worth trying, see what happens. > > Are you saying that you would like to see the code which implements a > more generic version of the peak_util "filter" on top of PELT? Not sure about peak_util, I was more thinking of an IIR/PID filter, as per the email thread referenced below. Doesn't make sense to hide that in intel_pstate if it appears to be universally useful etc.. > IMO it could be a good exercise now that we agree we want to improve > PELT without replacing it. I think it would make sense to keep it inside sched_cpufreq for now. > > > For example, a task running 30 [ms] every 100 [ms] is a ~300 util_avg > > > task. With PELT, we get a signal which range between [120,550] with an > > > average of ~300 which is instead completely ignored. By capping the > > > decay we will get: > > > > > > decay_cap [ms] range average > > > 0 120:550 300 > > > 64 140:560 310 > > > 32 320:660 430 > > > > > > which means that still the raw PELT signal is wobbling and never > > > provides a consistent response to drive decisions. > > > > > > Thus, a "predictor" should be something which sample information from > > > PELT to provide a more consistent view, a sort of of low-pass filter > > > on top of the "dynamic metric" which is PELT. > > > > > > Should not such a "predictor" help on solving some of the issues > > > related to PELT slow ramp-up or fast ramp-down? > > > > I think intel_pstate recently added a local PID filter, I asked at the > > time if something like that should live in generic code, looks like > > maybe it should. > > That PID filter is not "just" a software implementation of the ACPI's > Collaborative Processor Performance Control (CPPC) when HWP hardware > is not provided by a certain processor? I think it was this thread: http://lkml.kernel.org/r/[email protected] It never really made sense such a filter should live in individual drivers.
