From: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
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>,
Pavel Machek <pavel@ucw.cz>,
"Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>,
Shaohua Li <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: Mon, 10 Aug 2009 07:30:05 +0530 [thread overview]
Message-ID: <20090810020005.GA1395@dirshya.in.ibm.com> (raw)
In-Reply-To: <200908091522.02898.rjw@sisk.pl>
* Rafael J. Wysocki <rjw@sisk.pl> [2009-08-09 15:22:02]:
> On Sunday 09 August 2009, Pavel Machek wrote:
> > Hi!
> >
> > > > Also, approaches such as [1] can make use of this
> > > > extended infrastructure instead of putting the CPU to an arbitrary C-state
> > > > when it is offlined, thereby providing the system administrator a rope to hang
> > > > himself with should he feel the need to do so.
> > > I didn't see the reason why administrator needs to know which state offline cpu
> > > should stay. Don't know about powerpc side, but in x86 side, it appears deepest
> > > C-state is already preferred.
> > >
> >
> > Agreed, deepest c-state is always best, there's no need to make it configurable.
>
> Unless it doesn't work.
Yes, this is one of the reason. Kernel will know about the deepest
sleep state and any restrictions and should set that as default in the
preferred_offline state. End-users and sys-admins need not change it,
default will be the deepest sleep state supported and allowed by the
system which may be different than the one supported by the processor.
This framework could allow the default to be set easily by other
userspace tools. These restrictions apply to cpuidle governor as
well, hence at some level both these subsystems should be in sync.
As described in this patch series, the meaning of offline cpu is
different in a virtualized system and this framework provides
flexibility of choice there. Platforms today do have a choice on what
state an offline cpu should reside, this framework is one of the
possible methods to exploit that choice and not restrict it due to
lack of OS flexibility.
--Vaidy
next prev parent reply other threads:[~2009-08-10 2:00 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 [this message]
2009-08-10 8:19 ` Pavel Machek
2009-08-11 0:22 ` Pallipadi, Venkatesh
2009-08-11 17:53 ` Dipankar Sarma
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=20090810020005.GA1395@dirshya.in.ibm.com \
--to=svaidy@linux.vnet.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).