From: Dipankar Sarma <dipankar@in.ibm.com>
To: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
Cc: "Brown, Len" <len.brown@intel.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Gautham R Shenoy <ego@in.ibm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Rafael J. Wysocki" <rjw@sisk.pl>, Pavel Machek <pavel@ucw.cz>,
"Li, Shaohua" <shaohua.li@intel.com>, Ingo Molnar <mingo@elte.hu>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"Darrick J. Wong" <djwong@us.ibm.com>
Subject: Re: [PATCH 0/3] cpu: idle state framework for offline CPUs.
Date: Tue, 11 Aug 2009 23:23:41 +0530 [thread overview]
Message-ID: <20090811175341.GA6328@in.ibm.com> (raw)
In-Reply-To: <1249950137.11545.38184.camel@localhost.localdomain>
On Mon, Aug 10, 2009 at 05:22:17PM -0700, Pallipadi, Venkatesh wrote:
> Also, I don't think using just the ACPI/BIOS supplied states in _CST is
> right thing to do for offline. _CST is meant for C-state and BIOS may
> not include some C-state in _CST if the system manufacturer thinks that
> the latency is too high for the state to be used as a C-state. That
> limitation applies for C-state as the cpu is expected to come out of
> C-state often and execute code handle interrupts etc. But, that
> restriction does not apply for offline online which is not as frequent
> as C-state entry and it already has big latency with startup IPI, and a
> whole baggage of CPU setup code. So, using BIOS CST info for CPU offline
> state doesn't seem right.
>
> May be having (to pick a number) 3 possible offline states for all
> platforms with one for halt equivalent and one for deepest possible that
> CPU can handle and one for deepest possible that platform likes for
> C-states may make sense. Will keeps things simpler in terms of usage
> expectations and possibly reduce the misuse oppurtubity?
Yes, I think we should let specific archs advertise a small set
of possible offline states and let the cpu state be set to one of
those only keeping the platform implementation robust.
Here is variant of the original proposal from Gautham -
/sys/devices/system/cpu/cpu<number>/available_states
For example, available state for an Intel platform could be exported as
"online dealloc C1 C6"
online = fully up
dealloc = offline and de-allocated (as in virtualized environment)
C1 = C1 or C1E halt
C6 = C6 sleep
/sys/devices/system/cpu/cpu<number>/state
Writing any of the available states to this file triggers transition to that
state barring some transitions that are disallowed to keep things simple
(e.g. dealloc cpus support only transition to online).
/sys/devices/system/cpu/cpu<number>/online
Backward compatibility - online = 0 changes state to C6 or dealloc depending
on the platform. online = 1 changes state to online.
Would this make sense ?
Thanks
Dipankar
next prev parent reply other threads:[~2009-08-11 17:53 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-05 14:25 [PATCH 0/3] cpu: idle state framework for offline CPUs Gautham R Shenoy
2009-08-05 14:25 ` [PATCH 1/3] cpu: Offline state Framework Gautham R Shenoy
2009-08-05 14:26 ` [PATCH 2/3] cpu: Implement cpu-offline-state callbacks for pSeries Gautham R Shenoy
2009-08-05 14:26 ` [PATCH 3/3] pSeries: cpu: Cede CPU during a deactivate-offline Gautham R Shenoy
2009-08-06 1:58 ` [PATCH 0/3] cpu: idle state framework for offline CPUs Shaohua Li
2009-08-06 4:33 ` Vaidyanathan Srinivasan
2009-08-06 15:03 ` Peter Zijlstra
2009-08-06 15:13 ` Peter Zijlstra
2009-08-09 12:08 ` Pavel Machek
2009-08-06 13:48 ` Gautham R Shenoy
2009-08-07 1:02 ` Shaohua Li
2009-08-09 12:08 ` Pavel Machek
2009-08-09 13:22 ` Rafael J. Wysocki
2009-08-10 2:00 ` Vaidyanathan Srinivasan
2009-08-10 8:19 ` Pavel Machek
2009-08-11 0:22 ` Pallipadi, Venkatesh
2009-08-11 17:53 ` Dipankar Sarma [this message]
2009-08-12 11:58 ` Pavel Machek
2009-08-12 12:05 ` Peter Zijlstra
2009-08-12 19:57 ` Dipankar Sarma
2009-08-13 0:45 ` Len Brown
2009-08-13 4:59 ` Dipankar Sarma
2009-08-14 11:30 ` Pavel Machek
2009-08-16 18:26 ` Dipankar Sarma
2009-08-16 19:44 ` Balbir Singh
2009-08-16 21:53 ` Peter Zijlstra
2009-08-17 6:24 ` Dipankar Sarma
2009-08-17 7:15 ` Peter Zijlstra
2009-08-17 7:58 ` Dipankar Sarma
2009-08-17 14:40 ` Dipankar Sarma
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=20090811175341.GA6328@in.ibm.com \
--to=dipankar@in.ibm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=djwong@us.ibm.com \
--cc=ego@in.ibm.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mingo@elte.hu \
--cc=pavel@ucw.cz \
--cc=rjw@sisk.pl \
--cc=shaohua.li@intel.com \
--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).