From: Peter Zijlstra <peterz@infradead.org>
To: paulmck@linux.vnet.ibm.com
Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>,
akpm@linux-foundation.org, Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org,
Masami Hiramatsu <mhiramat@redhat.com>
Subject: Re: [patch 01/17] RCU read sched
Date: Sat, 02 Aug 2008 01:04:29 +0200 [thread overview]
Message-ID: <1217631869.9016.16.camel@twins> (raw)
In-Reply-To: <20080801211025.GR14851@linux.vnet.ibm.com>
On Fri, 2008-08-01 at 14:10 -0700, Paul E. McKenney wrote:
> On Tue, Jul 15, 2008 at 06:26:05PM -0400, Mathieu Desnoyers wrote:
> > Add rcu_read_lock_sched() and rcu_read_unlock_sched() to rcupdate.h to match the
> > recently added write-side call_rcu_sched() and rcu_barrier_sched(). They also
> > match the no-so-recently-added synchronize_sched().
> >
> > It will help following matching use of the update/read lock primitives. Those
> > new read lock will replace preempt_disable()/enable() used in pair with
> > RCU-classic synchronization.
>
> Looks good, but...
>
> synchronize_sched(), call_rcu_sched(), and rcu_barrier_sched() can also
> pair up with:
>
> o local_irq_save() and local_irq_restore()
> o local_irq_disable() and local_irq_enable()
> o spin_lock_irqsave() and spin_lock_irqrestore()
You can't actually, as on PREEMP_RT these will not actuall disable
preemption.
> o etc. etc.
>
> I do very much like the idea of marking the intent of matching with
> RCU, but am getting a bit queasy about adding rcu_read_lock_sched_irq()
> and so on.
I'm thinking that if you disable interrupts, you're doing that for
another reason than RCU, so I'm not seeing the need for
rcu_read_lock_sched_irq variants.
Also, we should be very careful with using the *sched* RCU variant as it
really relies on disabling preemption - we should only use it when there
really is no other option, as we generally prefer to keep stuff
preemptable.
> Thoughts? Other than having an rcu_read_lock_sched_nop() or some
> other window-dressing macro that doesn't really do anything? (Which
> might really be the right thing to do...)
Afraid you lost me here..
next prev parent reply other threads:[~2008-08-01 23:05 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-15 22:26 [patch 00/17] Tracepoints v4 for linux-next Mathieu Desnoyers
2008-07-15 22:26 ` [patch 01/17] RCU read sched Mathieu Desnoyers
2008-08-01 21:10 ` Paul E. McKenney
2008-08-01 23:04 ` Peter Zijlstra [this message]
2008-07-15 22:26 ` [patch 02/17] Kernel Tracepoints Mathieu Desnoyers
2008-07-24 15:08 ` Steven Rostedt
2008-07-24 20:18 ` Mathieu Desnoyers
2008-08-01 21:10 ` Paul E. McKenney
2008-08-04 15:17 ` Mathieu Desnoyers
2008-07-24 15:34 ` Steven Rostedt
2008-07-24 20:30 ` Mathieu Desnoyers
2008-07-24 22:22 ` Steven Rostedt
2008-07-24 15:39 ` Steven Rostedt
2008-07-24 20:37 ` [PATCH] Tracepoints use TABLE_SIZE macro Mathieu Desnoyers
2008-07-15 22:26 ` [patch 03/17] Tracepoints Documentation Mathieu Desnoyers
2008-07-15 22:26 ` [patch 04/17] Tracepoints Samples Mathieu Desnoyers
2008-07-15 22:26 ` [patch 05/17] LTTng instrumentation - irq Mathieu Desnoyers
2008-07-15 22:26 ` [patch 06/17] LTTng instrumentation - scheduler Mathieu Desnoyers
2008-07-16 8:30 ` Peter Zijlstra
2008-07-16 14:18 ` Mathieu Desnoyers
2008-07-15 22:26 ` [patch 07/17] LTTng instrumentation - timer Mathieu Desnoyers
2008-07-16 8:34 ` Peter Zijlstra
2008-07-16 14:34 ` Mathieu Desnoyers
2008-07-15 22:26 ` [patch 08/17] LTTng instrumentation - kernel Mathieu Desnoyers
2008-07-24 13:57 ` Steven Rostedt
2008-07-24 14:30 ` Mathieu Desnoyers
2008-07-24 15:13 ` Steven Rostedt
2008-07-15 22:26 ` [patch 09/17] LTTng instrumentation - filemap Mathieu Desnoyers
2008-07-16 8:35 ` Peter Zijlstra
2008-07-16 14:37 ` Mathieu Desnoyers
2008-07-17 6:25 ` Nick Piggin
2008-07-17 7:02 ` Mathieu Desnoyers
2008-07-17 7:11 ` Nick Piggin
2008-07-15 22:26 ` [patch 10/17] LTTng instrumentation - swap Mathieu Desnoyers
2008-07-16 8:39 ` Peter Zijlstra
2008-07-16 14:40 ` Mathieu Desnoyers
2008-07-16 14:47 ` Peter Zijlstra
2008-07-16 15:00 ` Mathieu Desnoyers
2008-07-16 15:50 ` KOSAKI Motohiro
2008-07-16 16:17 ` Mathieu Desnoyers
2008-07-15 22:26 ` [patch 11/17] LTTng instrumentation - memory page faults Mathieu Desnoyers
2008-07-15 22:26 ` [patch 12/17] LTTng instrumentation - page Mathieu Desnoyers
2008-07-16 8:41 ` Peter Zijlstra
2008-07-16 15:03 ` Mathieu Desnoyers
2008-07-15 22:26 ` [patch 13/17] LTTng instrumentation - hugetlb Mathieu Desnoyers
2008-07-15 22:26 ` [patch 14/17] LTTng instrumentation - net Mathieu Desnoyers
2008-07-15 22:26 ` [patch 15/17] LTTng instrumentation - ipv4 Mathieu Desnoyers
2008-07-15 22:26 ` [patch 16/17] LTTng instrumentation - ipv6 Mathieu Desnoyers
2008-07-15 22:26 ` [patch 17/17] ftrace port to tracepoints Mathieu Desnoyers
2008-07-16 8:51 ` [patch 00/17] Tracepoints v4 for linux-next Peter Zijlstra
2008-07-18 15:41 ` Masami Hiramatsu
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=1217631869.9016.16.camel@twins \
--to=peterz@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@polymtl.ca \
--cc=mhiramat@redhat.com \
--cc=mingo@elte.hu \
--cc=paulmck@linux.vnet.ibm.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).