From: Mark Lord <lkml@rtr.ca>
To: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
Cc: Arjan van de Ven <arjan@infradead.org>,
Andrew Morton <akpm@linux-foundation.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: Sat, 05 Jan 2008 11:27:21 -0500 [thread overview]
Message-ID: <477FAFE9.6090809@rtr.ca> (raw)
In-Reply-To: <924EFEDD5F540B4284297C4DC59F3DEE4FCC51@orsmsx423.amr.corp.intel.com>
Pallipadi, Venkatesh wrote:
>> -----Original Message-----
>> From: Mark Lord [mailto:lkml@rtr.ca]
..
>> Okay, with !CONFIG_CPU_IDLE, this works fine -- same as 2.6.23
>> and earlier.
>>
>
> Good to know. Atleast we do not have a regression for 2.6.24 now.
..
Agreed. We're happy here, for now.
>>> Meanwhile, can you give a short summary of how behaviour differs
>>> between CONFIG_CPU_IDLE and !CONFIG_CPU_IDLE ??
>>>
>>> I'm not at all clear on how this really affects things.
>
> With CPU_IDLE, the C-state policy is removed from acpi driver. Ideally
> policy should have nothing to do with ACPI, as ACPI only provides the
> C-state mechanisms. So, with CPU_IDLE, it is not easy to control this
> variable through a acpi driver module at run time. Also, the latency
> interface that was mentioned before is to serve the same purpose in a
> more clear manner (based on the wakeup latency) instead of a C-state
> number which may not mean much from the end user point of view.
>
> I will look at why latency does not work on a single core system
> soon(Was that with UP kernel or SMP kernel?). That way we will have a
> proper cover for this with CPU_IDLE in future.
..
That was with a UP kernel on a UP box.
The latency thingie really seemed to have little or no effect,
whereas setting max_cstate=1 has a quite noticeable positive impact.
Things seemed okay (with the latency thingie) on the SMP machine,
but with two cores it is probably simply more forgiving.
cheers
next prev parent reply other threads:[~2008-01-05 16:27 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 [this message]
2008-01-06 21:34 ` Mark Lord
2008-01-07 7:18 ` Andrew Morton
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=477FAFE9.6090809@rtr.ca \
--to=lkml@rtr.ca \
--cc=abelay@novell.com \
--cc=akpm@linux-foundation.org \
--cc=arjan@infradead.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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).