lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 18 Feb 2019 23:03:03 +0100 From: "Rafael J. Wysocki" <rjw@...ysocki.net> To: Doug Smythies <dsmythies@...us.net> Cc: 'Linux PM' <linux-pm@...r.kernel.org>, 'Srinivas Pandruvada' <srinivas.pandruvada@...ux.intel.com>, 'LKML' <linux-kernel@...r.kernel.org> Subject: Re: [PATCH v2] cpufreq: intel_pstate: Rework iowait boosting to be less aggressive On Sunday, February 17, 2019 8:25:37 PM CET Doug Smythies wrote: > On 2019.02.07 03:51 Rafael J. Wysocki wrote: > > > From: Rafael J. Wysocki <rafael.j.wysocki@...el.com> > > > > The current iowait boosting mechanism in intel_pstate_update_util() > > is quite aggressive, as it goes to the maximum P-state right away, > > and may cause excessive amounts of energy to be used, which is not > > desirable and arguably isn't necessary too. > > > > Follow commit a5a0809bc58e ("cpufreq: schedutil: Make iowait boost > > more energy efficient") that reworked the analogous iowait boost > > mechanism in the schedutil governor and make the iowait boosting > > in intel_pstate_update_util() work along the same lines. > > > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com> > > --- > > > > -> v2: > > * Follow the Doug's suggestion and drop the immediate jump to > > max P-state if boost is max. The code is simpler this way and > > the perf impact should not be noticeable on average. > > Hi Rafael, > > Something has broken on my incoming e-mail sorting stuff, and I > missed this one (and some others). > > This V2 is not actually what I was proposing. I was O.K. with > the immediate jump, but I didn't want the set_pstate step > by-passed if it was already at max because that would also > by-pass the trace sample, if it was enabled. > > Anyway, this V2 seems O.K. to me. I tested it compared to V1 > and, as you mentioned, wasn't able to detect any energy consumption > or performance differences. Thanks for the confirmation!
Powered by blists - more mailing lists