From patchwork Wed Mar 28 06:38:45 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Francisco Jerez X-Patchwork-Id: 10312257 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id B541960467 for ; Wed, 28 Mar 2018 06:44:11 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A71B32993B for ; Wed, 28 Mar 2018 06:44:11 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 9BB50299E0; Wed, 28 Mar 2018 06:44:11 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 595E82993B for ; Wed, 28 Mar 2018 06:44:11 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id BDC606E25C; Wed, 28 Mar 2018 06:44:10 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) by gabe.freedesktop.org (Postfix) with ESMTPS id 69A066E205 for ; Wed, 28 Mar 2018 06:43:51 +0000 (UTC) Received: from cotinga.riseup.net (cotinga-pn.riseup.net [10.0.1.164]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id 217531A0A14; Tue, 27 Mar 2018 23:43:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1522219431; bh=C71Rp/iQjMssVFwVVpR8JrcJHlf8zFRnrdzPJ9W39so=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pYjQtdtbJ8gPhBzSkqC3awELvN5ibK8TEu5P4kjNpEwlvQekL6O/xrRDhTNgiDvFh huPkKVS8RpI3nJqE48PbnNl+MCvGaxD5Yb0K8QiMVFUH9PsXaAC/iKI+daFOdjO0hu BfnxHUzcM+qhiJ1e/RHnK5Sww3X3NCT0oBbptVp8= X-Riseup-User-ID: 3E35D6323A426CFE8E58A6616CF2D2EB887501196187D3D332FFE9998225FD5E Received: from [127.0.0.1] (localhost [127.0.0.1]) by cotinga.riseup.net with ESMTPSA id CA4AA6C439; Tue, 27 Mar 2018 23:43:50 -0700 (PDT) From: Francisco Jerez To: linux-pm@vger.kernel.org, intel-gfx@lists.freedesktop.org, Srinivas Pandruvada Date: Tue, 27 Mar 2018 23:38:45 -0700 Message-Id: <20180328063845.4884-10-currojerez@riseup.net> In-Reply-To: <20180328063845.4884-1-currojerez@riseup.net> References: <20180328063845.4884-1-currojerez@riseup.net> Subject: [Intel-gfx] [PATCH 9/9] drm/i915/execlists: Report GPU rendering as IO activity to cpufreq. X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Eero Tamminen , "Rafael J. Wysocki" MIME-Version: 1.0 Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Virus-Scanned: ClamAV using ClamSMTP This allows cpufreq governors to realize when the system becomes non-CPU-bound due to GPU rendering activity, which will cause the intel_pstate LP controller to behave more conservatively: CPU energy usage will be reduced when there isn't a good chance for system performance to scale with CPU frequency. This leaves additional TDP budget available for the GPU to reach higher frequencies, which is translated into an improvement in graphics performance to the extent that the workload remains TDP-limited (Most non-trivial graphics benchmarks out there improve significantly in TDP-constrained platforms, see the cover letter for some numbers). If the workload isn't (anymore) TDP-limited performance should stay roughly constant, but energy usage will be divided by a similar factor. The intel_pstate LP controller is only enabled on BXT+ small-core platforms at this point, so this shouldn't have any effect on other systems. Signed-off-by: Francisco Jerez --- drivers/gpu/drm/i915/intel_lrc.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 3a69b367e565..721f915115bd 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -132,6 +132,7 @@ * */ #include +#include #include #include @@ -379,11 +380,13 @@ execlists_context_schedule_in(struct i915_request *rq) { execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_IN); intel_engine_context_in(rq->engine); + cpufreq_io_active_begin(); } static inline void execlists_context_schedule_out(struct i915_request *rq) { + cpufreq_io_active_end(); intel_engine_context_out(rq->engine); execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_OUT); } @@ -726,6 +729,7 @@ execlists_cancel_port_requests(struct intel_engine_execlists * const execlists) struct i915_request *rq = port_request(port); GEM_BUG_ON(!execlists->active); + cpufreq_io_active_end(); intel_engine_context_out(rq->engine); execlists_context_status_change(rq,