On 09/30, Paul E. McKenney wrote:
>
> On Sun, Sep 30, 2007 at 04:02:09PM -0700, Davide Libenzi wrote:
> > On Sun, 30 Sep 2007, Oleg Nesterov wrote:
> >
> > > Ah, but I asked the different question. We must see CPU 1's stores by
> > > definition, but what about CPU 0's stores (which could be seen
On 09/30, Paul E. McKenney wrote:
On Sun, Sep 30, 2007 at 04:02:09PM -0700, Davide Libenzi wrote:
On Sun, 30 Sep 2007, Oleg Nesterov wrote:
Ah, but I asked the different question. We must see CPU 1's stores by
definition, but what about CPU 0's stores (which could be seen by CPU 1)?
On Mon, Oct 01, 2007 at 03:09:16PM -0700, Davide Libenzi wrote:
> On Mon, 1 Oct 2007, Paul E. McKenney wrote:
>
> > That would indeed be one approach that CPU designers could take to
> > avoid being careless or sadistic. ;-)
>
> That'd be the easier (unique maybe) approach too for them, from an
On Mon, 1 Oct 2007, Paul E. McKenney wrote:
> That would indeed be one approach that CPU designers could take to
> avoid being careless or sadistic. ;-)
That'd be the easier (unique maybe) approach too for them, from an silicon
complexity POV. Distinguishing between different CPUs stores once
On Mon, Oct 01, 2007 at 11:44:25AM -0700, Davide Libenzi wrote:
> On Sun, 30 Sep 2007, Paul E. McKenney wrote:
>
> > On Sun, Sep 30, 2007 at 04:02:09PM -0700, Davide Libenzi wrote:
> > > On Sun, 30 Sep 2007, Oleg Nesterov wrote:
> > >
> > > > Ah, but I asked the different question. We must see
On Sun, 30 Sep 2007, Paul E. McKenney wrote:
> On Sun, Sep 30, 2007 at 04:02:09PM -0700, Davide Libenzi wrote:
> > On Sun, 30 Sep 2007, Oleg Nesterov wrote:
> >
> > > Ah, but I asked the different question. We must see CPU 1's stores by
> > > definition, but what about CPU 0's stores (which
On Sun, Sep 30, 2007 at 08:31:02PM +0400, Oleg Nesterov wrote:
> On 09/28, Paul E. McKenney wrote:
> >
> > On Fri, Sep 28, 2007 at 06:47:14PM +0400, Oleg Nesterov wrote:
> > > Ah, I was confused by the comment,
> > >
> > > smp_mb(); /* Don't call for memory barriers before we see zero. */
> >
On Sun, Sep 30, 2007 at 04:02:09PM -0700, Davide Libenzi wrote:
> On Sun, 30 Sep 2007, Oleg Nesterov wrote:
>
> > Ah, but I asked the different question. We must see CPU 1's stores by
> > definition, but what about CPU 0's stores (which could be seen by CPU 1)?
> >
> > Let's take a "real life"
On Sun, Sep 30, 2007 at 04:02:09PM -0700, Davide Libenzi wrote:
On Sun, 30 Sep 2007, Oleg Nesterov wrote:
Ah, but I asked the different question. We must see CPU 1's stores by
definition, but what about CPU 0's stores (which could be seen by CPU 1)?
Let's take a real life example,
On Sun, Sep 30, 2007 at 08:31:02PM +0400, Oleg Nesterov wrote:
On 09/28, Paul E. McKenney wrote:
On Fri, Sep 28, 2007 at 06:47:14PM +0400, Oleg Nesterov wrote:
Ah, I was confused by the comment,
smp_mb(); /* Don't call for memory barriers before we see zero. */
On Sun, 30 Sep 2007, Paul E. McKenney wrote:
On Sun, Sep 30, 2007 at 04:02:09PM -0700, Davide Libenzi wrote:
On Sun, 30 Sep 2007, Oleg Nesterov wrote:
Ah, but I asked the different question. We must see CPU 1's stores by
definition, but what about CPU 0's stores (which could be seen
On Mon, Oct 01, 2007 at 11:44:25AM -0700, Davide Libenzi wrote:
On Sun, 30 Sep 2007, Paul E. McKenney wrote:
On Sun, Sep 30, 2007 at 04:02:09PM -0700, Davide Libenzi wrote:
On Sun, 30 Sep 2007, Oleg Nesterov wrote:
Ah, but I asked the different question. We must see CPU 1's stores
On Mon, 1 Oct 2007, Paul E. McKenney wrote:
That would indeed be one approach that CPU designers could take to
avoid being careless or sadistic. ;-)
That'd be the easier (unique maybe) approach too for them, from an silicon
complexity POV. Distinguishing between different CPUs stores once
On Mon, Oct 01, 2007 at 03:09:16PM -0700, Davide Libenzi wrote:
On Mon, 1 Oct 2007, Paul E. McKenney wrote:
That would indeed be one approach that CPU designers could take to
avoid being careless or sadistic. ;-)
That'd be the easier (unique maybe) approach too for them, from an silicon
On Sun, 30 Sep 2007, Oleg Nesterov wrote:
> Ah, but I asked the different question. We must see CPU 1's stores by
> definition, but what about CPU 0's stores (which could be seen by CPU 1)?
>
> Let's take a "real life" example,
>
> A = B = X = 0;
> P = Q =
>
>
On 09/28, Paul E. McKenney wrote:
>
> On Fri, Sep 28, 2007 at 06:47:14PM +0400, Oleg Nesterov wrote:
> > Ah, I was confused by the comment,
> >
> > smp_mb(); /* Don't call for memory barriers before we see zero. */
> > ^^
> >
On 09/28, Paul E. McKenney wrote:
On Fri, Sep 28, 2007 at 06:47:14PM +0400, Oleg Nesterov wrote:
Ah, I was confused by the comment,
smp_mb(); /* Don't call for memory barriers before we see zero. */
^^
So, in fact,
On Sun, 30 Sep 2007, Oleg Nesterov wrote:
Ah, but I asked the different question. We must see CPU 1's stores by
definition, but what about CPU 0's stores (which could be seen by CPU 1)?
Let's take a real life example,
A = B = X = 0;
P = Q = A;
CPU_0
On Fri, Sep 28, 2007 at 06:47:14PM +0400, Oleg Nesterov wrote:
> On 09/27, Paul E. McKenney wrote:
> >
> > On Wed, Sep 26, 2007 at 07:13:51PM +0400, Oleg Nesterov wrote:
> > >
> > > Yes, yes, I see now. We really need this barriers, except I think
> > > rcu_try_flip_idle() can use wmb. However, I
On 09/27, Paul E. McKenney wrote:
>
> On Wed, Sep 26, 2007 at 07:13:51PM +0400, Oleg Nesterov wrote:
> >
> > Yes, yes, I see now. We really need this barriers, except I think
> > rcu_try_flip_idle() can use wmb. However, I have a bit offtopic question,
> >
> > // rcu_try_flip_waitzero()
> >
On 09/27, Paul E. McKenney wrote:
On Wed, Sep 26, 2007 at 07:13:51PM +0400, Oleg Nesterov wrote:
Yes, yes, I see now. We really need this barriers, except I think
rcu_try_flip_idle() can use wmb. However, I have a bit offtopic question,
// rcu_try_flip_waitzero()
if (A ==
On Fri, Sep 28, 2007 at 06:47:14PM +0400, Oleg Nesterov wrote:
On 09/27, Paul E. McKenney wrote:
On Wed, Sep 26, 2007 at 07:13:51PM +0400, Oleg Nesterov wrote:
Yes, yes, I see now. We really need this barriers, except I think
rcu_try_flip_idle() can use wmb. However, I have a bit
On Wed, Sep 26, 2007 at 07:13:51PM +0400, Oleg Nesterov wrote:
> On 09/23, Paul E. McKenney wrote:
> >
> > On Sun, Sep 23, 2007 at 09:38:07PM +0400, Oleg Nesterov wrote:
> > > Isn't DEFINE_PER_CPU_SHARED_ALIGNED better for rcu_flip_flag and
> > > rcu_mb_flag?
> >
> > Looks like it to me, thank
On Wed, Sep 26, 2007 at 07:13:51PM +0400, Oleg Nesterov wrote:
On 09/23, Paul E. McKenney wrote:
On Sun, Sep 23, 2007 at 09:38:07PM +0400, Oleg Nesterov wrote:
Isn't DEFINE_PER_CPU_SHARED_ALIGNED better for rcu_flip_flag and
rcu_mb_flag?
Looks like it to me, thank you for the tip!
On 09/23, Paul E. McKenney wrote:
>
> On Sun, Sep 23, 2007 at 09:38:07PM +0400, Oleg Nesterov wrote:
> > Isn't DEFINE_PER_CPU_SHARED_ALIGNED better for rcu_flip_flag and
> > rcu_mb_flag?
>
> Looks like it to me, thank you for the tip!
>
> Hmmm... Why not the same for rcu_data? I guess because
On 09/23, Paul E. McKenney wrote:
On Sun, Sep 23, 2007 at 09:38:07PM +0400, Oleg Nesterov wrote:
Isn't DEFINE_PER_CPU_SHARED_ALIGNED better for rcu_flip_flag and
rcu_mb_flag?
Looks like it to me, thank you for the tip!
Hmmm... Why not the same for rcu_data? I guess because there is
On Sun, Sep 23, 2007 at 09:38:07PM +0400, Oleg Nesterov wrote:
> On 09/10, Paul E. McKenney wrote:
> >
> > Work in progress, not for inclusion.
>
> Impressive work! a couple of random newbie's questions...
Thank you for the kind words, and most especially for the careful review!!!
And Oleg, I
On 09/10, Paul E. McKenney wrote:
>
> Work in progress, not for inclusion.
Impressive work! a couple of random newbie's questions...
> --- linux-2.6.22-b-fixbarriers/include/linux/rcupdate.h 2007-07-19
> 14:02:36.0 -0700
> +++ linux-2.6.22-c-preemptrcu/include/linux/rcupdate.h
On 09/10, Paul E. McKenney wrote:
Work in progress, not for inclusion.
Impressive work! a couple of random newbie's questions...
--- linux-2.6.22-b-fixbarriers/include/linux/rcupdate.h 2007-07-19
14:02:36.0 -0700
+++ linux-2.6.22-c-preemptrcu/include/linux/rcupdate.h
On Sun, Sep 23, 2007 at 09:38:07PM +0400, Oleg Nesterov wrote:
On 09/10, Paul E. McKenney wrote:
Work in progress, not for inclusion.
Impressive work! a couple of random newbie's questions...
Thank you for the kind words, and most especially for the careful review!!!
And Oleg, I don't
On Fri, Sep 21, 2007 at 10:56:56PM -0400, Steven Rostedt wrote:
>
> [ sneaks away from the family for a bit to answer emails ]
[ same here, now that you mention it... ]
> --
> On Fri, 21 Sep 2007, Paul E. McKenney wrote:
>
> > On Fri, Sep 21, 2007 at 09:19:22PM -0400, Steven Rostedt wrote:
> >
On Fri, Sep 21, 2007 at 11:15:42PM -0400, Steven Rostedt wrote:
> On Fri, 21 Sep 2007, Paul E. McKenney wrote:
> > On Fri, Sep 21, 2007 at 09:15:03PM -0400, Steven Rostedt wrote:
> > > On Fri, 21 Sep 2007, Paul E. McKenney wrote:
> > > > On Fri, Sep 21, 2007 at 10:40:03AM -0400, Steven Rostedt
[took off Ingo, because he has my ISP blacklisted, and I'm tired of
getting those return mail messages. He can read LKML or you can re-CC
him. Sad since this is a topic he should be reading. ]
--
On Fri, 21 Sep 2007, Paul E. McKenney wrote:
> On Fri, Sep 21, 2007 at 09:15:03PM -0400, Steven
[ sneaks away from the family for a bit to answer emails ]
--
On Fri, 21 Sep 2007, Paul E. McKenney wrote:
> On Fri, Sep 21, 2007 at 09:19:22PM -0400, Steven Rostedt wrote:
> >
> > --
> > On Fri, 21 Sep 2007, Paul E. McKenney wrote:
> > > >
> > > > In any case, I will be looking at the
On Fri, Sep 21, 2007 at 09:15:03PM -0400, Steven Rostedt wrote:
> On Fri, 21 Sep 2007, Paul E. McKenney wrote:
> > On Fri, Sep 21, 2007 at 10:40:03AM -0400, Steven Rostedt wrote:
> > > On Mon, Sep 10, 2007 at 11:34:12AM -0700, Paul E. McKenney wrote:
[ . . . ]
> > > > + /*
> > > > +
On Fri, Sep 21, 2007 at 09:19:22PM -0400, Steven Rostedt wrote:
>
> --
> On Fri, 21 Sep 2007, Paul E. McKenney wrote:
> > >
> > > In any case, I will be looking at the scenarios more carefully. If
> > > it turns out that GP_STAGES can indeed be cranked down a bit, well,
> > > that is an easy
--
On Fri, 21 Sep 2007, Paul E. McKenney wrote:
> >
> > In any case, I will be looking at the scenarios more carefully. If
> > it turns out that GP_STAGES can indeed be cranked down a bit, well,
> > that is an easy change! I just fired off a POWER run with GP_STAGES
> > set to 3, will let you
On Fri, 21 Sep 2007, Paul E. McKenney wrote:
> On Fri, Sep 21, 2007 at 10:40:03AM -0400, Steven Rostedt wrote:
> > On Mon, Sep 10, 2007 at 11:34:12AM -0700, Paul E. McKenney wrote:
>
> Covering the pieces that weren't in Peter's reply. ;-)
>
> And thank you -very- much for the careful and
On Fri, Sep 21, 2007 at 04:03:43PM -0700, Paul E. McKenney wrote:
> On Fri, Sep 21, 2007 at 11:20:48AM -0400, Steven Rostedt wrote:
> > On Mon, Sep 10, 2007 at 11:34:12AM -0700, Paul E. McKenney wrote:
[ . . . ]
> > Paul,
> >
> > Looking further into this, I still think this is a bit of
On Fri, Sep 21, 2007 at 10:40:03AM -0400, Steven Rostedt wrote:
> On Mon, Sep 10, 2007 at 11:34:12AM -0700, Paul E. McKenney wrote:
Covering the pieces that weren't in Peter's reply. ;-)
And thank you -very- much for the careful and thorough review!!!
> > #endif /* __KERNEL__ */
> > #endif
On Fri, Sep 21, 2007 at 07:23:09PM -0400, Steven Rostedt wrote:
> --
> On Fri, 21 Sep 2007, Paul E. McKenney wrote:
>
> > If you do a synchronize_rcu() it might well have to wait through the
> > following sequence of states:
> >
> > Stage 0: (might have to wait through part of this to get out of
--
On Fri, 21 Sep 2007, Paul E. McKenney wrote:
>
> If you do a synchronize_rcu() it might well have to wait through the
> following sequence of states:
>
> Stage 0: (might have to wait through part of this to get out of "next" queue)
> rcu_try_flip_idle_state,/* "I" */
>
On Fri, Sep 21, 2007 at 11:20:48AM -0400, Steven Rostedt wrote:
> On Mon, Sep 10, 2007 at 11:34:12AM -0700, Paul E. McKenney wrote:
> > +
> > +/*
> > + * PREEMPT_RCU data structures.
> > + */
> > +
> > +#define GP_STAGES 4
> > +struct rcu_data {
> > + spinlock_t lock; /* Protect
On Fri, Sep 21, 2007 at 06:31:12PM -0400, Steven Rostedt wrote:
> On Fri, Sep 21, 2007 at 05:46:53PM +0200, Peter Zijlstra wrote:
> > On Fri, 21 Sep 2007 10:40:03 -0400 Steven Rostedt <[EMAIL PROTECTED]>
> > wrote:
> >
> > > On Mon, Sep 10, 2007 at 11:34:12AM -0700, Paul E. McKenney wrote:
> >
>
On Fri, Sep 21, 2007 at 05:46:53PM +0200, Peter Zijlstra wrote:
> On Fri, 21 Sep 2007 10:40:03 -0400 Steven Rostedt <[EMAIL PROTECTED]>
> wrote:
>
> > On Mon, Sep 10, 2007 at 11:34:12AM -0700, Paul E. McKenney wrote:
>
>
> > Can you have a pointer somewhere that explains these states. And not a
On Fri, Sep 21, 2007 at 05:46:53PM +0200, Peter Zijlstra wrote:
> On Fri, 21 Sep 2007 10:40:03 -0400 Steven Rostedt <[EMAIL PROTECTED]>
> wrote:
>
> > On Mon, Sep 10, 2007 at 11:34:12AM -0700, Paul E. McKenney wrote:
>
> > Can you have a pointer somewhere that explains these states. And not a
> >
On Fri, 21 Sep 2007 10:40:03 -0400 Steven Rostedt <[EMAIL PROTECTED]>
wrote:
> On Mon, Sep 10, 2007 at 11:34:12AM -0700, Paul E. McKenney wrote:
> Can you have a pointer somewhere that explains these states. And not a
> "it's in this paper or directory". Either have a short discription here,
>
On Mon, Sep 10, 2007 at 11:34:12AM -0700, Paul E. McKenney wrote:
> +
> +/*
> + * PREEMPT_RCU data structures.
> + */
> +
> +#define GP_STAGES 4
> +struct rcu_data {
> + spinlock_t lock; /* Protect rcu_data fields. */
> + longcompleted; /* Number of last
On Mon, Sep 10, 2007 at 11:34:12AM -0700, Paul E. McKenney wrote:
>
> #endif /* __KERNEL__ */
> #endif /* __LINUX_RCUCLASSIC_H */
> diff -urpNa -X dontdiff linux-2.6.22-b-fixbarriers/include/linux/rcupdate.h
> linux-2.6.22-c-preemptrcu/include/linux/rcupdate.h
> ---
On Mon, Sep 10, 2007 at 11:34:12AM -0700, Paul E. McKenney wrote:
#endif /* __KERNEL__ */
#endif /* __LINUX_RCUCLASSIC_H */
diff -urpNa -X dontdiff linux-2.6.22-b-fixbarriers/include/linux/rcupdate.h
linux-2.6.22-c-preemptrcu/include/linux/rcupdate.h
---
On Mon, Sep 10, 2007 at 11:34:12AM -0700, Paul E. McKenney wrote:
+
+/*
+ * PREEMPT_RCU data structures.
+ */
+
+#define GP_STAGES 4
+struct rcu_data {
+ spinlock_t lock; /* Protect rcu_data fields. */
+ longcompleted; /* Number of last completed
On Fri, 21 Sep 2007 10:40:03 -0400 Steven Rostedt [EMAIL PROTECTED]
wrote:
On Mon, Sep 10, 2007 at 11:34:12AM -0700, Paul E. McKenney wrote:
Can you have a pointer somewhere that explains these states. And not a
it's in this paper or directory. Either have a short discription here,
or
On Fri, Sep 21, 2007 at 05:46:53PM +0200, Peter Zijlstra wrote:
On Fri, 21 Sep 2007 10:40:03 -0400 Steven Rostedt [EMAIL PROTECTED]
wrote:
On Mon, Sep 10, 2007 at 11:34:12AM -0700, Paul E. McKenney wrote:
Can you have a pointer somewhere that explains these states. And not a
it's in
On Fri, Sep 21, 2007 at 05:46:53PM +0200, Peter Zijlstra wrote:
On Fri, 21 Sep 2007 10:40:03 -0400 Steven Rostedt [EMAIL PROTECTED]
wrote:
On Mon, Sep 10, 2007 at 11:34:12AM -0700, Paul E. McKenney wrote:
Can you have a pointer somewhere that explains these states. And not a
it's in
On Fri, Sep 21, 2007 at 06:31:12PM -0400, Steven Rostedt wrote:
On Fri, Sep 21, 2007 at 05:46:53PM +0200, Peter Zijlstra wrote:
On Fri, 21 Sep 2007 10:40:03 -0400 Steven Rostedt [EMAIL PROTECTED]
wrote:
On Mon, Sep 10, 2007 at 11:34:12AM -0700, Paul E. McKenney wrote:
Can you
On Fri, Sep 21, 2007 at 11:20:48AM -0400, Steven Rostedt wrote:
On Mon, Sep 10, 2007 at 11:34:12AM -0700, Paul E. McKenney wrote:
+
+/*
+ * PREEMPT_RCU data structures.
+ */
+
+#define GP_STAGES 4
+struct rcu_data {
+ spinlock_t lock; /* Protect rcu_data fields.
--
On Fri, 21 Sep 2007, Paul E. McKenney wrote:
If you do a synchronize_rcu() it might well have to wait through the
following sequence of states:
Stage 0: (might have to wait through part of this to get out of next queue)
rcu_try_flip_idle_state,/* I */
On Fri, Sep 21, 2007 at 07:23:09PM -0400, Steven Rostedt wrote:
--
On Fri, 21 Sep 2007, Paul E. McKenney wrote:
If you do a synchronize_rcu() it might well have to wait through the
following sequence of states:
Stage 0: (might have to wait through part of this to get out of next
On Fri, Sep 21, 2007 at 10:40:03AM -0400, Steven Rostedt wrote:
On Mon, Sep 10, 2007 at 11:34:12AM -0700, Paul E. McKenney wrote:
Covering the pieces that weren't in Peter's reply. ;-)
And thank you -very- much for the careful and thorough review!!!
#endif /* __KERNEL__ */
#endif /*
On Fri, Sep 21, 2007 at 04:03:43PM -0700, Paul E. McKenney wrote:
On Fri, Sep 21, 2007 at 11:20:48AM -0400, Steven Rostedt wrote:
On Mon, Sep 10, 2007 at 11:34:12AM -0700, Paul E. McKenney wrote:
[ . . . ]
Paul,
Looking further into this, I still think this is a bit of overkill. We
On Fri, 21 Sep 2007, Paul E. McKenney wrote:
On Fri, Sep 21, 2007 at 10:40:03AM -0400, Steven Rostedt wrote:
On Mon, Sep 10, 2007 at 11:34:12AM -0700, Paul E. McKenney wrote:
Covering the pieces that weren't in Peter's reply. ;-)
And thank you -very- much for the careful and thorough
--
On Fri, 21 Sep 2007, Paul E. McKenney wrote:
In any case, I will be looking at the scenarios more carefully. If
it turns out that GP_STAGES can indeed be cranked down a bit, well,
that is an easy change! I just fired off a POWER run with GP_STAGES
set to 3, will let you know how it
On Fri, Sep 21, 2007 at 09:19:22PM -0400, Steven Rostedt wrote:
--
On Fri, 21 Sep 2007, Paul E. McKenney wrote:
In any case, I will be looking at the scenarios more carefully. If
it turns out that GP_STAGES can indeed be cranked down a bit, well,
that is an easy change! I just
On Fri, Sep 21, 2007 at 09:15:03PM -0400, Steven Rostedt wrote:
On Fri, 21 Sep 2007, Paul E. McKenney wrote:
On Fri, Sep 21, 2007 at 10:40:03AM -0400, Steven Rostedt wrote:
On Mon, Sep 10, 2007 at 11:34:12AM -0700, Paul E. McKenney wrote:
[ . . . ]
+ /*
+* Take the
[ sneaks away from the family for a bit to answer emails ]
--
On Fri, 21 Sep 2007, Paul E. McKenney wrote:
On Fri, Sep 21, 2007 at 09:19:22PM -0400, Steven Rostedt wrote:
--
On Fri, 21 Sep 2007, Paul E. McKenney wrote:
In any case, I will be looking at the scenarios more
[took off Ingo, because he has my ISP blacklisted, and I'm tired of
getting those return mail messages. He can read LKML or you can re-CC
him. Sad since this is a topic he should be reading. ]
--
On Fri, 21 Sep 2007, Paul E. McKenney wrote:
On Fri, Sep 21, 2007 at 09:15:03PM -0400, Steven
On Fri, Sep 21, 2007 at 11:15:42PM -0400, Steven Rostedt wrote:
On Fri, 21 Sep 2007, Paul E. McKenney wrote:
On Fri, Sep 21, 2007 at 09:15:03PM -0400, Steven Rostedt wrote:
On Fri, 21 Sep 2007, Paul E. McKenney wrote:
On Fri, Sep 21, 2007 at 10:40:03AM -0400, Steven Rostedt wrote:
On Fri, Sep 21, 2007 at 10:56:56PM -0400, Steven Rostedt wrote:
[ sneaks away from the family for a bit to answer emails ]
[ same here, now that you mention it... ]
--
On Fri, 21 Sep 2007, Paul E. McKenney wrote:
On Fri, Sep 21, 2007 at 09:19:22PM -0400, Steven Rostedt wrote:
--
On Fri, Sep 21, 2007 at 12:17:21AM -0400, Steven Rostedt wrote:
> [ continued here from comment on patch 1]
>
> On Mon, Sep 10, 2007 at 11:34:12AM -0700, Paul E. McKenney wrote:
> > /* softirq mask and active fields moved to irq_cpustat_t in
> > diff -urpNa -X dontdiff
> >
On Fri, Sep 21, 2007 at 12:17:21AM -0400, Steven Rostedt wrote:
> [ continued here from comment on patch 1]
>
> On Mon, Sep 10, 2007 at 11:34:12AM -0700, Paul E. McKenney wrote:
> > /* softirq mask and active fields moved to irq_cpustat_t in
> > diff -urpNa -X dontdiff
> >
[ continued here from comment on patch 1]
On Mon, Sep 10, 2007 at 11:34:12AM -0700, Paul E. McKenney wrote:
> /* softirq mask and active fields moved to irq_cpustat_t in
> diff -urpNa -X dontdiff linux-2.6.22-b-fixbarriers/include/linux/rcuclassic.h
>
[ continued here from comment on patch 1]
On Mon, Sep 10, 2007 at 11:34:12AM -0700, Paul E. McKenney wrote:
/* softirq mask and active fields moved to irq_cpustat_t in
diff -urpNa -X dontdiff linux-2.6.22-b-fixbarriers/include/linux/rcuclassic.h
On Fri, Sep 21, 2007 at 12:17:21AM -0400, Steven Rostedt wrote:
[ continued here from comment on patch 1]
On Mon, Sep 10, 2007 at 11:34:12AM -0700, Paul E. McKenney wrote:
/* softirq mask and active fields moved to irq_cpustat_t in
diff -urpNa -X dontdiff
On Fri, Sep 21, 2007 at 12:17:21AM -0400, Steven Rostedt wrote:
[ continued here from comment on patch 1]
On Mon, Sep 10, 2007 at 11:34:12AM -0700, Paul E. McKenney wrote:
/* softirq mask and active fields moved to irq_cpustat_t in
diff -urpNa -X dontdiff
Work in progress, not for inclusion.
This patch implements a new version of RCU which allows its read-side
critical sections to be preempted. It uses a set of counter pairs
to keep track of the read-side critical sections and flips them
when all tasks exit read-side critical section. The details
Work in progress, not for inclusion.
This patch implements a new version of RCU which allows its read-side
critical sections to be preempted. It uses a set of counter pairs
to keep track of the read-side critical sections and flips them
when all tasks exit read-side critical section. The details
76 matches
Mail list logo
