From: Jacob Pan <jacob.jun.pan@linux.intel.com>
To: paulmck@linux.vnet.ibm.com
Cc: Linux PM <linux-pm@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Rafael Wysocki <rafael.j.wysocki@intel.com>,
Len Brown <len.brown@intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>,
Zhang Rui <rui.zhang@intel.com>, Rob Landley <rob@landley.net>,
Arjan van de Ven <arjan@linux.intel.com>
Subject: Re: [PATCH 3/3] PM: Introduce Intel PowerClamp Driver
Date: Tue, 13 Nov 2012 13:39:22 -0800 [thread overview]
Message-ID: <20121113133922.47144a50@chromoly> (raw)
In-Reply-To: <20121113211602.GA30150@linux.vnet.ibm.com>
On Tue, 13 Nov 2012 13:16:02 -0800
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> > Please refer to Documentation/thermal/intel_powerclamp.txt for more
> > details.
>
> If I read this correctly, this forces a group of CPUs into idle for
> about 600 milliseconds at a time. This would indeed delay grace
> periods, which could easily result in user complaints. Also, given
> the default RCU_BOOST_DELAY of 500 milliseconds in kernels enabling
> RCU_BOOST, you would see needless RCU priority boosting.
>
the default idle injection duration is 6ms. we adjust the sleep
interval to ensure idle ratio. So the idle duration stays the same once
set. So would it be safe to delay grace period for this small amount in
exchange for less over head in each injection period?
> Of course, if the idle period extended for longer, you would see RCU
> CPU stall warnings. And if the idle period extended indefinitely, you
> could hang the system -- the RCU callbacks on the idled CPU could not
> be invoked, and if one of those RCU callbacks was waking someone up,
> that someone would not be woken up.
>
for the same algorithm, idle duration is not extended. the injected
idle loop also yield to pending softirqs, i guess that is what rcu
callbacks are using?
> It looks like you could end up with part of the system powerclamped
> in some situations, and with all of it powerclamped in other
> situations. Is that the case, or am I confused?
>
could you explain the part that is partially powerclamped?
> Thanx, Paul
[Jacob Pan]
--
Thanks,
Jacob
next prev parent reply other threads:[~2012-11-13 21:39 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-12 22:03 [PATCH 0/3] pm: Intel powerclamp driver Jacob Pan
2012-11-12 22:03 ` [PATCH 1/3] tick: export nohz tick idle symbols for module use Jacob Pan
2012-11-12 22:03 ` [PATCH 2/3] x86/nmi: export local_touch_nmi() symbol for modules Jacob Pan
2012-11-12 22:03 ` [PATCH 3/3] PM: Introduce Intel PowerClamp Driver Jacob Pan
2012-11-13 6:33 ` Joe Perches
2012-11-13 6:55 ` Jacob Pan
2012-11-13 21:16 ` Paul E. McKenney
2012-11-13 21:39 ` Jacob Pan [this message]
2012-11-13 22:23 ` Paul E. McKenney
2012-11-13 22:45 ` Arjan van de Ven
2012-11-13 23:02 ` Rafael J. Wysocki
2012-11-14 0:03 ` Paul E. McKenney
2012-11-14 0:03 ` Paul E. McKenney
2012-11-14 0:08 ` Arjan van de Ven
2012-11-14 1:14 ` Jacob Pan
2012-11-14 1:34 ` Paul E. McKenney
2012-11-14 2:59 ` Arjan van de Ven
2012-11-15 3:22 ` Paul E. McKenney
2012-11-14 1:24 ` Jacob Pan
2012-11-13 21:56 ` Arjan van de Ven
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=20121113133922.47144a50@chromoly \
--to=jacob.jun.pan@linux.intel.com \
--cc=arjan@linux.intel.com \
--cc=hpa@zytor.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulmck@linux.vnet.ibm.com \
--cc=rafael.j.wysocki@intel.com \
--cc=rob@landley.net \
--cc=rui.zhang@intel.com \
--cc=tglx@linutronix.de \
/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).