Hi, On 11/04/18 09:26, Francisco Jerez wrote: > Francisco Jerez <currojerez@xxxxxxxxxx> writes: > > > Hi Srinivas, > > > > Srinivas Pandruvada <srinivas.pandruvada@xxxxxxxxxxxxxxx> writes: > > > >> On Tue, 2018-04-10 at 15:28 -0700, Francisco Jerez wrote: > >>> Francisco Jerez <currojerez@xxxxxxxxxx> writes: > >>> > >> [...] > >> > >> > >>> For the case anyone is wondering what's going on, Srinivas pointed me > >>> at > >>> a larger idle power usage increase off-list, ultimately caused by the > >>> low-latency heuristic as discussed in the paragraph above. I have a > >>> v2 > >>> of PATCH 6 that gives the controller a third response curve roughly > >>> intermediate between the low-latency and low-power states of this > >>> revision, which avoids the energy usage increase while C0 residency > >>> is > >>> low (e.g. during idle) expected for v1. The low-latency behavior of > >>> this revision is still going to be available based on a heuristic (in > >>> particular when a realtime-priority task is scheduled). We're > >>> carrying > >>> out some additional testing, I'll post the code here eventually. > >> > >> Please try sched-util governor also. There is a frequency-invariant > >> patch, which I can send you (This eventually will be pushed by Peter). > >> We want to avoid complexity to intel-pstate for non HWP power sensitive > >> platforms as far as possible. > >> > > > > Unfortunately the schedutil governor (whether frequency invariant or > > not) has the exact same energy efficiency issues as the present > > intel_pstate non-HWP governor. Its response is severely underdamped > > leading to energy-inefficient behavior for any oscillating non-CPU-bound > > workload. To exacerbate that problem the frequency is maxed out on > > frequent IO waiting just like the current intel_pstate cpu-load > > "just like" here is possibly somewhat unfair to the schedutil governor, > admittedly its progressive IOWAIT boosting behavior seems somewhat less > wasteful than the intel_pstate non-HWP governor's IOWAIT boosting > behavior, but it's still largely unhelpful on IO-bound conditions. Sorry if I jump in out of the blue, but what you are trying to solve looks very similar to what IPA [1] is targeting as well. I might be wrong (I'll try to spend more time reviewing your set), but my first impression is that we should try to solve similar problems with a more general approach that could benefit different sys/archs. I'm Cc-ing some Arm folks... Best, - Juri [1] https://developer.arm.com/open-source/intelligent-power-allocation _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
