Re: [PATCH 0/9] GPU-bound energy efficiency improvements for the intel_pstate driver.

From: Francisco Jerez <currojerez@riseup.net>
To: Peter Zijlstra <peterz@infradead.org>
Cc: intel-gfx@lists.freedesktop.org, linux-pm@vger.kernel.org,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Eero Tamminen <eero.t.tamminen@intel.com>,
	Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Subject: Re: [PATCH 0/9] GPU-bound energy efficiency improvements for the intel_pstate driver.
Date: Fri, 13 Apr 2018 18:57:39 -0700	[thread overview]
Message-ID: <87d0z21re4.fsf@riseup.net> (raw)
In-Reply-To: <20180413181537.GS4064@hirez.programming.kicks-ass.net>

[-- Attachment #1.1.1: Type: text/plain, Size: 1876 bytes --]

Peter Zijlstra <peterz@infradead.org> writes:

> On Thu, Apr 12, 2018 at 12:55:39PM -0700, Francisco Jerez wrote:
>> Actually assuming that a single geometric feature of the power curve is
>> known -- it being convex in the frequency range allowed by the policy
>> (which is almost always the case, not only for Intel CPUs), the optimal
>> frequency for an IO-bound workload is fully independent of the exact
>> power curve -- It's just the minimum CPU frequency that's able to keep
>> the bottlenecking IO device at 100% utilization. 
>
> I think that is difficult to determine with the information at hand. We
> have lost all device information by the time we reach the scheduler.

I assume you mean it's difficult to tell whether the workload is
CPU-bound or IO-bound?  Yeah, it's non-trivial to determine whether the
system is bottlenecking on IO, it requires additional infrastructure to
keep track of IO utilization (that's the purpose of PATCH 1), and even
then it involves some heuristic assumptions which are not guaranteed
fail-proof, so the controller needs to be prepared for things to behave
reasonably when the assumptions deviate from reality (see the comments
in PATCH 6 for more details on what happens in such cases) -- How
frequently that happens in practice is what determines how far the
controller's response will be from the optimally energy-efficient
behavior in a real workload.  It seems to work fairly well in practice,
at least in the sample of test-cases I've been able to gather data from
so far.

Anyway that's the difficult part.  Once (if) you know you're IO-bound,
determining the optimal (most energy-efficient) CPU frequency is
relatively straightforward, and doesn't require knowledge of the exact
power curve of the CPU (beyond clamping the controller response to the
convexity region of the power curve).

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx