From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762113AbXKHUFP (ORCPT ); Thu, 8 Nov 2007 15:05:15 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1761157AbXKHUFB (ORCPT ); Thu, 8 Nov 2007 15:05:01 -0500 Received: from mga09.intel.com ([134.134.136.24]:15503 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1761075AbXKHUFB (ORCPT ); Thu, 8 Nov 2007 15:05:01 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.21,391,1188802800"; d="scan'208";a="198966242" Date: Thu, 8 Nov 2007 12:03:52 -0800 From: Mark Gross To: Andrew Morton Cc: Valdis.Kletnieks@vt.edu, linux-kernel@vger.kernel.org Subject: Re: 2.6.23-mm1 breaks C-state support on Intel T7200 x86_64 Message-ID: <20071108200352.GA5538@linux.intel.com> Reply-To: mgross@linux.intel.com References: <3624.1194542384@turing-police.cc.vt.edu> <20071108100212.0cbff318.akpm@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071108100212.0cbff318.akpm@linux-foundation.org> User-Agent: Mutt/1.5.11 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 08, 2007 at 10:02:12AM -0800, Andrew Morton wrote: > > On Thu, 08 Nov 2007 12:19:44 -0500 Valdis.Kletnieks@vt.edu wrote: > > (Sorry for not reporting this sooner - I haven't been running off battery > > much in the last 3 weeks, so I didn't notice it till now...) > > > > Dell Latitude D820 laptop, T7200 Core2 Duo CPU, x86_64 kernel. > > > > As reported by 'powertop' on a basically idle machine: > > > > 2.6.23-mm1: > > > > Cn Avg residency P-states (frequencies) > > C0 (cpu running) (100.0%) 2.00 Ghz 0.8% > > C1 0.0ms ( 0.0%) 1.67 Ghz 0.0% > > C2 0.0ms ( 0.0%) 1333 Mhz 0.0% > > C3 0.0ms ( 0.0%) 1000 Mhz 99.2% > > > > 2.6.23-rc8-mm2: > > > > Cn Avg residency P-states (frequencies) > > C0 (cpu running) ( 0.3%) 2.00 Ghz 0.0% > > C1 0.0ms ( 0.0%) 1.67 Ghz 0.0% > > C2 0.0ms ( 0.0%) 1333 Mhz 0.0% > > C3 31.5ms (99.7%) 1000 Mhz 100.0% > > > > In addition, the ACPI power estimate reported about 25 watts for 23-mm1, > > but only 21 watts for -rc8-mm2, a significant regression. > > > > I bisected this down to this set of patches: > > > > pm-qos-infrastructure-and-interface.patch > > pm-qos-infrastructure-and-interface-fix.patch > > pm-qos-infrastructure-and-interface-vs-git-acpi.patch > > pm-qos-infrastructure-and-interface-vs-git-acpi-2.patch > > latencyc-use-qos-infrastructure.patch > > > > The patch says: > > > > To register the default pm_qos target for the specific parameter, the > > process must open one of /dev/[cpu_dma_latency, network_latency, > > network_throughput] > > > > As long as the device node is held open that process has a registered > > requirement on the parameter. The name of the requirement is > > "process_" derived from the current->pid from within the open system > > call. > > > > I shouldn't have to have a process open a /dev/file, write a number, and then > > stay around forever so the file doesn't close in order to get the same behavior > > I was getting by default before. What needs to happen to get this to not > > be a behavior regression/change? > > > > That's a great report, thanks. Over to you, Mark ;) > > btw, I also have a note here that these patches caused Rafael to see an > smp_call_function() inside local_irq_save(). Did that get fixed? Ah, I see the problem. I think I posted a fix to this. The problem is that what's in the mm1 tree has a parameter PM_QOS_IDLE that needed to be PM_QOS_CPU_DMA_LATENCY. I'm not sure what's in the current MM tree at this point so I can't say its been fixed. Is there an easy way from me to see what's currently in MM? FWIW I think I fixed this when I fixed up Rafael's issue. Would you like me to send out a re-fresh patch against 2.6.23-mm1? --mgross