From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757545AbXK3WWi (ORCPT ); Fri, 30 Nov 2007 17:22:38 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753376AbXK3WWX (ORCPT ); Fri, 30 Nov 2007 17:22:23 -0500 Received: from smtp2.linux-foundation.org ([207.189.120.14]:33201 "EHLO smtp2.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753322AbXK3WWW (ORCPT ); Fri, 30 Nov 2007 17:22:22 -0500 Date: Fri, 30 Nov 2007 14:20:58 -0800 From: Andrew Morton To: "Pallipadi, Venkatesh" Cc: lkml@rtr.ca, abelay@novell.com, lenb@kernel.org, mlord@pobox.com, rjw@sisk.pl, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org Subject: Re: + restore-missing-sysfs-max_cstate-attr.patch added to -mm tree Message-Id: <20071130142058.816d1693.akpm@linux-foundation.org> In-Reply-To: <924EFEDD5F540B4284297C4DC59F3DEE2FAE6A@orsmsx423.amr.corp.intel.com> References: <200711302153.lAULrZ7n026255@imap1.linux-foundation.org> <924EFEDD5F540B4284297C4DC59F3DEE2FAE6A@orsmsx423.amr.corp.intel.com> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.20; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 30 Nov 2007 14:06:55 -0800 "Pallipadi, Venkatesh" wrote: Please dont go off-list like this. I put Mark's original mailing list cc's back. > > I will have to Nack this. The reason max_cstate was initentionally > removed due to couple of reasons: It broke userspace without any warning or migration period, afaict. > 1) All in kernel users of max_cstate should rather be using > pm_qos/latency interfaces. All such max_cstate usages must already be > migrated. That code isn't merged. > 2) Supporting max_cstate as a dynamic parameter cleanly is no longer > possible in acpi/processor_idle.c as the C-state policy has moved to > cpuidle instead. It can be done if it is needed. But, just below patch > will not really work with cpuidle. > > Selecting max_cstate at boot time as a debug option still works without > this patch. > > So, just this patch will not get back the functionality with cpuidle. > Infact changing it at run time will have no effect. Question however is: > Is there a real need to revive this parameter so that user can change > max_cstate at run time? It is not known whether Mark is actually writing to this thing. Perhaps read-only permissions would be a suitable fix?