From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org, mingo@elte.hu,
laijs@cn.fujitsu.com, dipankar@in.ibm.com,
akpm@linux-foundation.org, mathieu.desnoyers@efficios.com,
josh@joshtriplett.org, niv@us.ibm.com, tglx@linutronix.de,
rostedt@goodmis.org, Valdis.Kletnieks@vt.edu,
dhowells@redhat.com, eric.dumazet@gmail.com, darren@dvhart.com,
fweisbec@gmail.com, patches@linaro.org,
torvalds@linux-foundation.org
Subject: Re: [PATCH RFC] rcu: Make __rcu_read_lock() inlinable
Date: Mon, 26 Mar 2012 22:15:15 -0700 [thread overview]
Message-ID: <20120327051515.GO2450@linux.vnet.ibm.com> (raw)
In-Reply-To: <1332787630.16159.182.camel@twins>
On Mon, Mar 26, 2012 at 08:47:10PM +0200, Peter Zijlstra wrote:
> On Mon, 2012-03-26 at 11:32 -0700, Paul E. McKenney wrote:
> >
> > I could inline them into sched.h, if you are agreeable.
>
> Sure, or put it in kernel/sched/core.c.
That was my first thought, but there is a use of switch_to() in
arch/um/drivers/mconsole_kern.c.
> > I am a bit concerned about putting them both together because I am betting
> > that at least some of the architectures having tracing in switch_to(),
> > which I currently do not handle well.
>
> I would hope not.. there's a generic trace_sched_switch() and
> switch_to() is supposed to be black magic. I'd be fine breaking that as
> long as we can detect it.
Hmmm... I am not yet sure whether it is easier to make RCU use legal
in switch_to() or to detect it. I am inclined to take whatever course
is easiest, which is likely to make it legal. :-/
> > At the moment, the ways I can
> > think of to handle it well require saving before the switch and restoring
> > afterwards. Otherwise, I can end up with the ->rcu_read_unlock_special
> > flags getting associated with the wrong RCU read-side critical section,
> > as happened last year.
> >
> > Preemption is disabled at this point, correct?
>
> Yeah, and soon we'll have interrupts disabled as well (on all archs,
> currently only ARM has interrupts enabled at this point).
Good to know!
> > Hmmm... One way that I could reduce the overhead that preemptible RCU
> > imposes on the scheduler would be to move the task_struct queuing from
> > its current point upon entry to the scheduler to just before switch_to().
> > (The _bh and _sched quiescent states still need to remain at scheduler
> > entry.) That would mean that RCU would not queue tasks that entered
> > the scheduler, but did not actually do a context switch.
>
> That would make sense anyhow, right? No point in queueing a task if you
> didn't actually switch away from it.
Also it would simplify the save and restore operation, I believe.
> > Would that be helpful?
>
> For now that's preemptible rcu only, and as such a somewhat niche
> feature (iirc its not enabled in the big distros) so I don't think it
> matters too much. But yeah, would be nice.
OK, let me see what works best.
Thanx, Paul
next prev parent reply other threads:[~2012-03-27 5:15 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-25 20:52 [PATCH RFC] rcu: Make __rcu_read_lock() inlinable Paul E. McKenney
2012-03-26 7:54 ` Peter Zijlstra
2012-03-26 18:32 ` Paul E. McKenney
2012-03-26 18:47 ` Peter Zijlstra
2012-03-27 5:15 ` Paul E. McKenney [this message]
2012-03-27 12:26 ` Steven Rostedt
2012-03-27 16:39 ` Paul E. McKenney
2012-03-26 18:53 ` Steven Rostedt
2012-03-26 23:43 ` Paul E. McKenney
2012-03-27 8:06 ` Lai Jiangshan
2012-03-27 16:46 ` Paul E. McKenney
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=20120327051515.GO2450@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=akpm@linux-foundation.org \
--cc=darren@dvhart.com \
--cc=dhowells@redhat.com \
--cc=dipankar@in.ibm.com \
--cc=eric.dumazet@gmail.com \
--cc=fweisbec@gmail.com \
--cc=josh@joshtriplett.org \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@elte.hu \
--cc=niv@us.ibm.com \
--cc=patches@linaro.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/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.