linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Mark Lord <lkml@rtr.ca>
Cc: Venki Pallipadi <venkatesh.pallipadi@intel.com>,
	Arjan van de Ven <arjan@infradead.org>,
	abelay@novell.com, lenb@kernel.org, Ingo Molnar <mingo@elte.hu>,
	linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
	rjw@sisk.pl
Subject: Re: + restore-missing-sysfs-max_cstate-attr.patch added to -mm tree
Date: Sun, 6 Jan 2008 23:18:48 -0800	[thread overview]
Message-ID: <20080106231848.762e93c1.akpm@linux-foundation.org> (raw)
In-Reply-To: <47814958.3070208@rtr.ca>

On Sun, 06 Jan 2008 16:34:16 -0500 Mark Lord <lkml@rtr.ca> wrote:

> Venki Pallipadi wrote:
> > Reintroduce run time configurable max_cstate for !CPU_IDLE case.
> > 
> > Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
> > 
> > Index: linux-2.6.24-rc/drivers/acpi/processor_idle.c
> > ===================================================================
> > --- linux-2.6.24-rc.orig/drivers/acpi/processor_idle.c
> > +++ linux-2.6.24-rc/drivers/acpi/processor_idle.c
> > @@ -76,7 +76,11 @@ static void (*pm_idle_save) (void) __rea
> >  #define PM_TIMER_TICKS_TO_US(p)		(((p) * 1000)/(PM_TIMER_FREQUENCY/1000))
> >  
> >  static unsigned int max_cstate __read_mostly = ACPI_PROCESSOR_MAX_POWER;
> > +#ifdef CONFIG_CPU_IDLE
> >  module_param(max_cstate, uint, 0000);
> > +#else
> > +module_param(max_cstate, uint, 0644);
> > +#endif
> >  static unsigned int nocst __read_mostly;
> >  module_param(nocst, uint, 0000);
> >  
> ..
> 
> Can we get this patch upstream so that a stock 2.6.24 will work here?
> 

umm, OK, I queued it for 2.6.24.  I'll give people a day or so to comment
on this.

I had to invent some silly changlelog for it.  Please review it for
accuracy and completeness?

It isn't complete, really.  How come we only make max_cstate writeable if
CONFIG_CPU_IDLE=n?  What happens to people who were reliant upon writeable
max_cstate who now enable CPU_IDLE?  Things still break?  What is the
rationale behind this?  What constraints led us to this decision?




From: Venki Pallipadi <venkatesh.pallipadi@intel.com>

This was writeable in 2.6.23 but the cpuidle merge made it read-only.  But
some people's scripts (ie: Mark's) were writing to it.

As an unhappy compromise, make max_cstate writeable again if the kernel was
configured without CONFIG_CPU_IDLE.

Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Cc: Mark Lord <lkml@rtr.ca>
Cc: Arjan van de Ven <arjan@infradead.org>
Cc: Len Brown <lenb@kernel.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 drivers/acpi/processor_idle.c |    4 ++++
 1 file changed, 4 insertions(+)

diff -puN drivers/acpi/processor_idle.c~reintroduce-run-time-configurable-max_cstate-for-cpu_idle-case drivers/acpi/processor_idle.c
--- a/drivers/acpi/processor_idle.c~reintroduce-run-time-configurable-max_cstate-for-cpu_idle-case
+++ a/drivers/acpi/processor_idle.c
@@ -76,7 +76,11 @@ static void (*pm_idle_save) (void) __rea
 #define PM_TIMER_TICKS_TO_US(p)		(((p) * 1000)/(PM_TIMER_FREQUENCY/1000))
 
 static unsigned int max_cstate __read_mostly = ACPI_PROCESSOR_MAX_POWER;
+#ifdef CONFIG_CPU_IDLE
 module_param(max_cstate, uint, 0000);
+#else
+module_param(max_cstate, uint, 0644);
+#endif
 static unsigned int nocst __read_mostly;
 module_param(nocst, uint, 0000);
 
_


  reply	other threads:[~2008-01-07  7:19 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200711302153.lAULrZ7n026255@imap1.linux-foundation.org>
     [not found] ` <924EFEDD5F540B4284297C4DC59F3DEE2FAE6A@orsmsx423.amr.corp.intel.com>
2007-11-30 22:20   ` + restore-missing-sysfs-max_cstate-attr.patch added to -mm tree Andrew Morton
2007-11-30 22:37     ` Pallipadi, Venkatesh
2007-12-01  2:52       ` Mark Lord
2007-12-01  3:02         ` Arjan van de Ven
2007-12-01  3:14           ` Mark Lord
2007-12-01  3:18             ` Arjan van de Ven
2007-12-01  3:31               ` Mark Lord
2007-12-01  3:44                 ` Mark Lord
2007-12-01  3:48                   ` Mark Lord
2007-12-01  4:02                   ` Mark Lord
2007-12-01  4:31                     ` Mark Lord
2007-12-01 23:43                   ` 20000+ wake-ups/second in 2.6.24. Bug? Mark Lord
2007-12-01 23:46                     ` Arjan van de Ven
2007-12-01 23:55                       ` Mark Lord
2007-12-02  0:13                         ` Arjan van de Ven
2007-12-02  1:10                           ` Andres Freund
2007-12-02  0:20                         ` Rafael J. Wysocki
2008-02-04 17:29                           ` Mark Lord
2008-02-04 17:50                             ` Arjan van de Ven
2008-02-04 19:17                               ` Mark Lord
2007-12-02 14:41                     ` Adrian Bunk
2007-12-02 14:59                       ` Mark Lord
2007-12-02 15:12                         ` Adrian Bunk
2007-12-02 15:45                           ` Mark Lord
2007-12-02 15:45                           ` Mark Lord
2007-12-02 15:49                           ` Mark Lord
2008-01-02 23:41                 ` + restore-missing-sysfs-max_cstate-attr.patch added to -mm tree Mark Lord
2008-01-03  0:06                   ` Pallipadi, Venkatesh
2008-01-03  0:51                     ` Andrew Morton
2008-01-03  1:12                       ` Pallipadi, Venkatesh
2008-01-03  4:25                         ` Mark Lord
2008-01-03  4:18                     ` Mark Lord
2008-01-04  2:16                       ` Venki Pallipadi
2008-01-04  3:16                         ` Mark Lord
2008-01-04 21:52                           ` Mark Lord
2008-01-04 21:59                             ` Pallipadi, Venkatesh
2008-01-05 16:27                               ` Mark Lord
2008-01-06 21:34                         ` Mark Lord
2008-01-07  7:18                           ` Andrew Morton [this message]
2008-01-07 14:07                             ` Arjan van de Ven
2008-01-07 15:07                               ` Mark Lord
2008-01-07 14:18                             ` Pallipadi, Venkatesh
2008-01-07 15:06                             ` Mark Lord
2008-01-07 19:12                               ` Len Brown
2008-01-07 21:33                                 ` Mark Lord
2008-01-07 22:43                                   ` Len Brown
2007-12-01 10:17             ` Andrew Morton
2007-12-01 16:30               ` Arjan van de Ven
2007-12-05 11:17       ` Pavel Machek
2007-12-07 21:38         ` Pallipadi, Venkatesh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080106231848.762e93c1.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=abelay@novell.com \
    --cc=arjan@infradead.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkml@rtr.ca \
    --cc=mingo@elte.hu \
    --cc=rjw@sisk.pl \
    --cc=venkatesh.pallipadi@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).