From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: [RFC] Hack to avoid C-state reduction during graphics activity. Date: Mon, 1 Nov 2010 13:23:40 -0700 Message-ID: <1288643024-5706-1-git-send-email-eric@anholt.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from annarchy.freedesktop.org (annarchy.freedesktop.org [131.252.210.176]) by gabe.freedesktop.org (Postfix) with ESMTP id 8258E9E942 for ; Mon, 1 Nov 2010 13:24:02 -0700 (PDT) Received: from pollan.anholt.net (annarchy.freedesktop.org [127.0.0.1]) by annarchy.freedesktop.org (Postfix) with ESMTP id 0D23A13000D for ; Mon, 1 Nov 2010 13:24:02 -0700 (PDT) List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org This is a series I came up with as a result of KS discussions. The plan was to pin the CPU C state to keep the GPU going as fast as possible while it was active, since there's some relation between the two (we don't know for sure yet, per chipset, whether it's due to latency of DMA writes having to bring CPU state up, or reduced memory bandwidth due to bus frequency reduction, or other). The actual patch series doesn't achieve that -- a hint is provided to the scheduler and cpufreq/cpuidle, which may choose not to sleep as deeply as it would otherwise. I found a 1% performance difference in nexuiz on my Ironlake system from the last patch in this series (HEAD~1 didn't have a statistically significant effect). If that's all the difference, I'll drop this. It may pay off higher for non-Ironlake, in which case I'll work on a "proper" solution of actually clamping C-states while graphics is active.