From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Steven Rostedt <rostedt@goodmis.org>,
linux-rt-users@vger.kernel.org, mingo@elte.hu,
tglx@linutronix.de, dvhltc@us.ibm.com, tytso@us.ibm.com,
dmitry.torokhov@gmail.com, akpm@linux-foundation.org,
nickpiggin@yahoo.com.au
Subject: Re: [PATCH RFC -rt] updated synchronize_all_irqs implementation
Date: Wed, 26 Sep 2007 06:03:26 -0700 [thread overview]
Message-ID: <20070926130326.GC19496@linux.vnet.ibm.com> (raw)
In-Reply-To: <20070926102833.17f7c025@twins>
On Wed, Sep 26, 2007 at 10:28:33AM +0200, Peter Zijlstra wrote:
> On Tue, 25 Sep 2007 18:11:39 -0700 "Paul E. McKenney"
> <paulmck@linux.vnet.ibm.com> wrote:
>
> > On Wed, Sep 26, 2007 at 01:24:47AM +0200, Peter Zijlstra wrote:
> > > On Tue, 25 Sep 2007 16:02:45 -0400 (EDT) Steven Rostedt
> > > <rostedt@goodmis.org> wrote:
> > >
> > > > > This would of course require that synchronize_all_irqs() be in the
> > > > > RCU code rather than the irq code so that it could access the static
> > > > > wakeme_after_rcu() definition and the rcu_synchronize structure.
> > > > >
> > > > > Thoughts?
> > > >
> > > > I do like this better. Anyone else care to comment?
> > >
> > > I'm still wondering why the IRQ users cannot user proper RCU as it
> > > stands:
> >
> > Well, that was my initial proposal. ;-)
>
> handler:
> > > rcu_read_lock();
> > > foo = rcu_dereference(bar);
> > > if (foo)
> > > foo();
> > > rcu_read_unlock();
> >
>
> control routine (!handler)
> > > vs
> > >
> > > rcu_assign(foo, NULL);
> > > synchronize_rcu();
Ah, OK -- yes, that was what I originally proposed -- that individual
handlers using RCU place the rcu_read_lock() and rcu_read_unlock() as
needed.
> > > The implicit rcu_read_lock() as placed in handle_IRQ_event() seems
> > > misplaced.
> >
> > OK -- where would you put them instead? I have them covering the
> > call to the handler, so what am I missing here?
>
> in do_hardirq() (-rt) that is specific to threaded interrupts.
My concern there is that some of the functions called from do_hardirq()
can loop processing multiple interrupts. An interrupt storm, otherwise
harmless in -rt, could cause a very long RCU read-side critical section
if it happened within thread_edge_irq().
> That said, I'm wondering if we need this whole extra sync_all_irqs()
> thing. I'm just not getting why IRQ handlers should be an implicit RCU
> safe context.
Because they are in non-rt -- synchronize_sched() is guaranteed to
wait for all interrupt handlers. In contrast, in -rt, synchronize_sched()
only waits for hardirq. So Dmitry Torokhov asked for a primitive
that would wait for all irq handlers, whether threaded or not.
But given that he has not responded to this thread, perhaps he
found that synchronize_irq() worked for him.
Thanx, Paul
next prev parent reply other threads:[~2007-09-26 13:03 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-21 5:46 [PATCH RFC -rt] synchronize_all_irqs implementation Paul E. McKenney
2007-09-23 17:34 ` [PATCH RFC -rt] updated " Paul E. McKenney
2007-09-25 17:22 ` Steven Rostedt
2007-09-25 19:34 ` Paul E. McKenney
2007-09-25 20:02 ` Steven Rostedt
2007-09-25 23:24 ` Peter Zijlstra
2007-09-26 1:11 ` Paul E. McKenney
2007-09-26 8:28 ` Peter Zijlstra
2007-09-26 13:03 ` Paul E. McKenney [this message]
2007-09-26 13:16 ` Dmitry Torokhov
2007-09-26 15:56 ` Paul E. McKenney
2007-09-26 17:19 ` Dmitry Torokhov
2007-09-26 17:43 ` Paul E. McKenney
2007-09-26 17:47 ` Steven Rostedt
2007-09-26 17:44 ` Steven Rostedt
2007-09-26 19:55 ` Paul E. McKenney
2007-09-26 20:54 ` Peter Zijlstra
2007-09-26 21:07 ` Steven Rostedt
2007-09-26 21:42 ` Paul E. McKenney
2007-09-27 14:24 ` Dmitry Torokhov
2007-09-27 14:28 ` Steven Rostedt
2007-09-27 14:32 ` Dmitry Torokhov
2007-09-26 21:22 ` 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=20070926130326.GC19496@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=dmitry.torokhov@gmail.com \
--cc=dvhltc@us.ibm.com \
--cc=linux-rt-users@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=nickpiggin@yahoo.com.au \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=tytso@us.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 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.