From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>,
Arjan van de Ven <arjan@linux.intel.com>,
lenb@kernel.org, rjw@rjwysocki.net,
Eliezer Tamir <eliezer.tamir@linux.intel.com>,
Chris Leech <christopher.leech@intel.com>,
David Miller <davem@davemloft.net>,
rui.zhang@intel.com, Mike Galbraith <bitbucket@online.de>,
Ingo Molnar <mingo@kernel.org>,
hpa@zytor.com, Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Subject: Re: [PATCH 3/7] idle, thermal, acpi: Remove home grown idle implementations
Date: Fri, 22 Nov 2013 09:17:27 -0800 [thread overview]
Message-ID: <20131122171727.GT4138@linux.vnet.ibm.com> (raw)
In-Reply-To: <20131122113300.GM10022@twins.programming.kicks-ass.net>
On Fri, Nov 22, 2013 at 12:33:00PM +0100, Peter Zijlstra wrote:
> On Thu, Nov 21, 2013 at 08:20:36PM -0800, Paul E. McKenney wrote:
> > The 6ms to 25ms range should be just fine as far as normal RCU grace
> > periods are concerned. However, it does mean that expedited grace
> > periods could be delayed: They normally take a few tens of microseconds,
> > but if they were unlucky enough to show up during an idle injection,
> > they would be magnified by two to three orders of magnitude, which is
> > not pretty.
> >
> > Hence my suggestion of hooking into RCU on idle-injection start and end
> > so that RCU considers that time period to be idle. Just like it does
> > for user-mode execution on NO_HZ_FULL kernels, so I still don't see this
> > approach to be a problem. I must confess that I still don't understand
> > what Arjan doesn't like about it.
>
> Using these patches it would indeed use the RCU idle machinery as per
> the normal idle path.
OK, sorry for my confusion!
> If you can I can add more WARN_ON()s in play_idle() to ensure we're not
> called while holding any RCU locks.
An rcu_sleep_check() or something similar, please!
Thanx, Paul
next prev parent reply other threads:[~2013-11-22 17:17 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-20 16:04 [PATCH 0/7] Cure some vaux idle wrackage Peter Zijlstra
2013-11-20 16:04 ` [PATCH 1/7] x86, acpi, idle: Restructure the mwait idle routines Peter Zijlstra
2013-11-20 16:04 ` [PATCH 2/7] sched, preempt: Fixup missed PREEMPT_NEED_RESCHED folding Peter Zijlstra
2013-11-21 8:25 ` Peter Zijlstra
2013-11-20 16:04 ` [PATCH 3/7] idle, thermal, acpi: Remove home grown idle implementations Peter Zijlstra
2013-11-20 16:40 ` Arjan van de Ven
2013-11-20 16:59 ` Peter Zijlstra
2013-11-20 17:23 ` Thomas Gleixner
2013-11-20 17:23 ` Arjan van de Ven
2013-11-20 17:55 ` Thomas Gleixner
2013-11-20 18:21 ` Arjan van de Ven
2013-11-20 19:38 ` Thomas Gleixner
2013-11-20 22:08 ` Jacob Pan
2013-11-21 0:54 ` Jacob Pan
2013-11-21 8:21 ` Peter Zijlstra
2013-11-21 16:07 ` Paul E. McKenney
2013-11-21 16:21 ` Arjan van de Ven
2013-11-21 19:19 ` Paul E. McKenney
2013-11-21 19:45 ` Arjan van de Ven
2013-11-21 20:07 ` Paul E. McKenney
2013-11-22 0:10 ` Jacob Pan
2013-11-22 4:20 ` Paul E. McKenney
2013-11-22 11:33 ` Peter Zijlstra
2013-11-22 17:17 ` Paul E. McKenney [this message]
2013-11-21 16:29 ` Peter Zijlstra
2013-11-21 17:27 ` Paul E. McKenney
2013-11-20 16:04 ` [PATCH 4/7] preempt, locking: Rework local_bh_{dis,en}able() Peter Zijlstra
2013-11-20 16:04 ` [PATCH 5/7] locking: Optimize lock_bh functions Peter Zijlstra
2013-11-20 16:04 ` [PATCH 6/7] sched: Clean up preempt_enable_no_resched() abuse Peter Zijlstra
2013-11-20 18:02 ` Eliezer Tamir
2013-11-20 18:15 ` Peter Zijlstra
2013-11-20 20:14 ` Eliezer Tamir
2013-11-21 10:10 ` Peter Zijlstra
2013-11-21 13:26 ` Eliezer Tamir
2013-11-21 13:39 ` Peter Zijlstra
2013-11-22 6:56 ` Eliezer Tamir
2013-11-22 11:30 ` Peter Zijlstra
2013-11-26 7:15 ` Eliezer Tamir
2013-11-26 10:51 ` Thomas Gleixner
2013-11-20 16:04 ` [PATCH 7/7] preempt: Take away preempt_enable_no_resched() from modules Peter Zijlstra
2013-11-20 18:54 ` Jacob Pan
2013-11-20 19:00 ` Peter Zijlstra
2013-11-20 19:18 ` Peter Zijlstra
2013-11-20 19:29 ` Jacob Pan
2013-11-20 16:34 ` [PATCH 0/7] Cure some vaux idle wrackage Peter Zijlstra
2013-11-20 17:19 ` Jacob Pan
2013-11-20 17:24 ` Peter Zijlstra
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=20131122171727.GT4138@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=arjan@linux.intel.com \
--cc=bitbucket@online.de \
--cc=christopher.leech@intel.com \
--cc=davem@davemloft.net \
--cc=eliezer.tamir@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jacob.jun.pan@linux.intel.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=rafael.j.wysocki@intel.com \
--cc=rjw@rjwysocki.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.