On Thu, 12 Sep 2013, Ingo Molnar wrote:
> My NAK of the original patches stands until the debug checks are working
> and are put up for a merge. You were talking nonsense all around in this
> thread and I simply don't trust your promise, but I'll obviously trust a
> queued up fix.
You could just
On Thu, 12 Sep 2013, Ingo Molnar wrote:
>
> * Christoph Lameter wrote:
>
> > On Mon, 9 Sep 2013, Ingo Molnar wrote:
> >
> > > I saw those, he posted 'needs testing' patches. He still behaved
> > > passive-aggressively, pretending that it was some difficult task to
> > > perform, as if we were pul
* Christoph Lameter wrote:
> On Mon, 9 Sep 2013, Ingo Molnar wrote:
>
> > I saw those, he posted 'needs testing' patches. He still behaved
> > passive-aggressively, pretending that it was some difficult task to
> > perform, as if we were pulling his teeth.
>
> I need your review of those. I
* Christoph Lameter wrote:
> On Mon, 9 Sep 2013, Ingo Molnar wrote:
>
> > So my NAK stands: you are still in denial, you should stop the silly
> > arguing and you should stop wasting maintainer time. You need to
> > address PeterZ's review feedback and fix the bugs in your patches,
> > ASAP.
On Wed, Sep 11, 2013 at 11:49:16AM -0400, Steven Rostedt wrote:
> On Wed, 11 Sep 2013 08:23:31 -0700
> "Paul E. McKenney" wrote:
>
> > C'mon, Steven! I did say "after treating injuries"! In the opinion
> > of the surgeon, the only option was to ampute what was left of either
> > the _cpu(), _ta
On Wed, 11 Sep 2013 08:23:31 -0700
"Paul E. McKenney" wrote:
> C'mon, Steven! I did say "after treating injuries"! In the opinion
> of the surgeon, the only option was to ampute what was left of either
> the _cpu(), _task(), _thread(), or _you(). Heck, the damage was so
> severe that we couldn
On Wed, Sep 11, 2013 at 10:26:07AM -0400, Steven Rostedt wrote:
> On Wed, 11 Sep 2013 07:13:02 -0700
> "Paul E. McKenney" wrote:
>
> > On Mon, Sep 09, 2013 at 03:34:26PM -0700, Paul E. McKenney wrote:
> > > On Mon, Sep 09, 2013 at 05:59:17PM -0400, Steven Rostedt wrote:
> > > > On Mon, 9 Sep 2013
On Wed, 11 Sep 2013 07:13:02 -0700
"Paul E. McKenney" wrote:
> On Mon, Sep 09, 2013 at 03:34:26PM -0700, Paul E. McKenney wrote:
> > On Mon, Sep 09, 2013 at 05:59:17PM -0400, Steven Rostedt wrote:
> > > On Mon, 9 Sep 2013 17:40:26 -0400
> > > Mathieu Desnoyers wrote:
> > >
> > > > Agreed. So ho
On Mon, Sep 09, 2013 at 03:34:26PM -0700, Paul E. McKenney wrote:
> On Mon, Sep 09, 2013 at 05:59:17PM -0400, Steven Rostedt wrote:
> > On Mon, 9 Sep 2013 17:40:26 -0400
> > Mathieu Desnoyers wrote:
> >
> > > Agreed. So how about rcu_is_online() ?
> >
> > Nope, what about all_your_base_are_belon
On Mon, 9 Sep 2013, Ingo Molnar wrote:
> I saw those, he posted 'needs testing' patches. He still behaved
> passive-aggressively, pretending that it was some difficult task to
> perform, as if we were pulling his teeth.
I need your review of those. I will rediff as soon as rc1 is out to
send some
On Mon, 9 Sep 2013, Ingo Molnar wrote:
> So my NAK stands: you are still in denial, you should stop the silly
> arguing and you should stop wasting maintainer time. You need to address
> PeterZ's review feedback and fix the bugs in your patches, ASAP.
You are NAKing my patches that add the preemp
On Mon, 2013-09-09 at 14:49 +, Christoph Lameter wrote:
> Its just that PREEMPT kernels are
> not in use and AFAICT the full preempt stuff requires significant developer
> support and complicates the code without much benefit.
The openSUSE desktop kernel is PREEMPT, and presumably has users.
On Mon, Sep 09, 2013 at 05:59:17PM -0400, Steven Rostedt wrote:
> On Mon, 9 Sep 2013 17:40:26 -0400
> Mathieu Desnoyers wrote:
>
> > Agreed. So how about rcu_is_online() ?
>
> Nope, what about all_your_base_are_belong_to_rcu()?
Let's see if I can remember the candidates...
rcu_is_cpu_i
On Mon, 9 Sep 2013 17:40:26 -0400
Mathieu Desnoyers wrote:
> Agreed. So how about rcu_is_online() ?
Nope, what about all_your_base_are_belong_to_rcu()?
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
* Paul E. McKenney (paul...@linux.vnet.ibm.com) wrote:
> On Mon, Sep 09, 2013 at 01:29:08PM -0400, Mathieu Desnoyers wrote:
> > * Paul E. McKenney (paul...@linux.vnet.ibm.com) wrote:
> > > On Mon, Sep 09, 2013 at 12:34:22PM -0400, Steven Rostedt wrote:
> > [...]
> > > > "rcu_is_ignored()" or "rcu_i
On Mon, 9 Sep 2013 10:56:56 -0700
"Paul E. McKenney" wrote:
> Although I do like rcu_is_active() better than rcu_read_check(), my
> concern with rcu_is_active() is that it can easily be mistaken for a
> global state rather than a per-CPU/thread/task/whatever state.
rcu_is_active_local();
Altho
On Mon, Sep 09, 2013 at 02:36:39PM -0400, Steven Rostedt wrote:
> On Mon, 9 Sep 2013 10:56:56 -0700
> "Paul E. McKenney" wrote:
>
>
> > Although I do like rcu_is_active() better than rcu_read_check(), my
> > concern with rcu_is_active() is that it can easily be mistaken for a
> > global state ra
On Mon, Sep 09, 2013 at 12:40:44PM -0400, Steven Rostedt wrote:
> On Mon, 9 Sep 2013 09:22:15 -0700
> "Paul E. McKenney" wrote:
> > However, the API we are arguing about is deep within the implementation.
> > It is not at the level of rcu_read_lock(). It is something that should
> > not have that
On Mon, Sep 09, 2013 at 01:06:05PM -0400, Steven Rostedt wrote:
> On Mon, 9 Sep 2013 09:58:36 -0700
> "Paul E. McKenney" wrote:
>
>
> > > "rcu_is_ignored()" or "rcu_is_not_active()", "rcu_is_watching_you()"
> >
> > You know, I am strongly tempted by "rcu_is_watching_you()", but I have
> > this
On Mon, Sep 09, 2013 at 01:29:08PM -0400, Mathieu Desnoyers wrote:
> * Paul E. McKenney (paul...@linux.vnet.ibm.com) wrote:
> > On Mon, Sep 09, 2013 at 12:34:22PM -0400, Steven Rostedt wrote:
> [...]
> > > "rcu_is_ignored()" or "rcu_is_not_active()", "rcu_is_watching_you()"
> >
> > You know, I am
* Paul E. McKenney (paul...@linux.vnet.ibm.com) wrote:
> On Mon, Sep 09, 2013 at 12:34:22PM -0400, Steven Rostedt wrote:
[...]
> > "rcu_is_ignored()" or "rcu_is_not_active()", "rcu_is_watching_you()"
>
> You know, I am strongly tempted by "rcu_is_watching_you()", but I have
> this feeling that it
On Mon, Sep 09, 2013 at 09:55:11AM -0400, Steven Rostedt wrote:
> On Mon, 9 Sep 2013 06:46:05 -0700
> "Paul E. McKenney" wrote:
>
>
> > > Also, if its per-task, why don't we have this in the task struct? The
> > > current scheme makes the context switch more expensive -- is this the
> > > right
On Mon, 9 Sep 2013 09:22:15 -0700
"Paul E. McKenney" wrote:
> However, the API we are arguing about is deep within the implementation.
> It is not at the level of rcu_read_lock(). It is something that should
> not have that many invocations -- after all, the things using it are
> binding themse
On Mon, Sep 09, 2013 at 04:21:55PM +0200, Peter Zijlstra wrote:
> On Mon, Sep 09, 2013 at 06:23:43AM -0700, Paul E. McKenney wrote:
> > Peter, in the general case, you are quite correct. But this is a special
> > case where it really does work.
> >
> > The key point here is that preemption and mi
On Mon, 9 Sep 2013 09:09:20 -0700
"Paul E. McKenney" wrote:
> Oddly enough, the earliest implementations of RCU that I worked with
> back in the early 1990s had implementation but no concept. The concepts
> came later. Something about how dragging people through 1500 lines
> of highly optimize
On Mon, 9 Sep 2013 09:58:36 -0700
"Paul E. McKenney" wrote:
> > "rcu_is_ignored()" or "rcu_is_not_active()", "rcu_is_watching_you()"
>
> You know, I am strongly tempted by "rcu_is_watching_you()", but I have
> this feeling that it is too cute for its own good. ;-)
Sign of the times...
s/c/S/
On Mon, 9 Sep 2013 09:26:32 -0700
"Paul E. McKenney" wrote:
> Now if we can agree on the naming and the exact per-CPU incantation... ;-)
s/per-CPU/per-task/
/me runs away!!!
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord
On Mon, 9 Sep 2013 09:17:08 -0700
"Paul E. McKenney" wrote:
> On Mon, Sep 09, 2013 at 10:16:29AM -0400, Steven Rostedt wrote:
> > On Mon, 9 Sep 2013 06:56:56 -0700
> > "Paul E. McKenney" wrote:
> >
> >
> > > Indeed, there is on ongoing naming debate as well. About the only point
> > > of agre
On Mon, Sep 09, 2013 at 12:30:26PM -0400, Steven Rostedt wrote:
> On Mon, 9 Sep 2013 09:09:20 -0700
> "Paul E. McKenney" wrote:
>
> > Oddly enough, the earliest implementations of RCU that I worked with
> > back in the early 1990s had implementation but no concept. The concepts
> > came later.
On Mon, Sep 09, 2013 at 12:34:22PM -0400, Steven Rostedt wrote:
> On Mon, 9 Sep 2013 09:17:08 -0700
> "Paul E. McKenney" wrote:
>
> > On Mon, Sep 09, 2013 at 10:16:29AM -0400, Steven Rostedt wrote:
> > > On Mon, 9 Sep 2013 06:56:56 -0700
> > > "Paul E. McKenney" wrote:
> > >
> > >
> > > > Inde
On Mon, Sep 09, 2013 at 12:42:05PM -0400, Steven Rostedt wrote:
> On Mon, 9 Sep 2013 09:26:32 -0700
> "Paul E. McKenney" wrote:
>
>
> > Now if we can agree on the naming and the exact per-CPU incantation... ;-)
>
> s/per-CPU/per-task/
>
> /me runs away!!!
Me too, given my previous experience
On Mon, Sep 09, 2013 at 04:40:38PM +0200, Frederic Weisbecker wrote:
> > If the state migrates with a task from one CPU to another, it's a task
> > state.
>
> This applies to preempt_count as well.
This is in fact true. Its something I'd like to cure, but currently the
PREEMPT_ACTIVE state makes
On Mon, Sep 09, 2013 at 10:16:29AM -0400, Steven Rostedt wrote:
> On Mon, 9 Sep 2013 06:56:56 -0700
> "Paul E. McKenney" wrote:
>
>
> > Indeed, there is on ongoing naming debate as well. About the only point
> > of agreement thus far is that the current names are inadequate. ;-)
> >
> > My cur
On Mon, Sep 09, 2013 at 06:53:20AM -0700, Paul E. McKenney wrote:
> On Mon, Sep 09, 2013 at 03:36:04PM +0200, Peter Zijlstra wrote:
> > On Mon, Sep 09, 2013 at 06:23:43AM -0700, Paul E. McKenney wrote:
> > > And guys, I have to say that the advice on which per-CPU primitive to use
> > > varies wild
On Mon, Sep 09, 2013 at 03:24:55PM +, Christoph Lameter wrote:
> On Mon, 9 Sep 2013, Peter Zijlstra wrote:
>
> > > Slander. Certainly validation is good. Its just that PREEMPT kernels are
> > > not in use
> >
> > Complete bullshit, its part of the mainline kernel, lots of people run
> > them -
On Mon, Sep 09, 2013 at 11:20:57AM -0400, Steven Rostedt wrote:
> On Mon, 9 Sep 2013 16:40:38 +0200
> Frederic Weisbecker wrote:
>
> > On Mon, Sep 09, 2013 at 09:29:17AM -0400, Steven Rostedt wrote:
> > > On Mon, 9 Sep 2013 09:21:42 -0400
> > > Steven Rostedt wrote:
> > >
> > >
> > > > Especi
* Steven Rostedt wrote:
> On Mon, 9 Sep 2013 18:00:24 +0200
> Ingo Molnar wrote:
>
> > So my NAK stands: you are still in denial, you should stop the silly
> > arguing and you should stop wasting maintainer time. You need to
> > address PeterZ's review feedback and fix the bugs in your patch
On Mon, Sep 09, 2013 at 11:39:05AM -0400, Steven Rostedt wrote:
> On Mon, 9 Sep 2013 11:20:57 -0400
> Steven Rostedt wrote:
>
> > > It's a bit the same with spinlocks. spinlocks aren't a task
> > > synchronization
> > > but a CPU synchronization. It's low level. Of course a task can't sleep
> >
On Mon, 9 Sep 2013 18:00:24 +0200
Ingo Molnar wrote:
> So my NAK stands: you are still in denial, you should stop the silly
> arguing and you should stop wasting maintainer time. You need to address
> PeterZ's review feedback and fix the bugs in your patches, ASAP.
To Christoph's credit. He di
On Mon, 9 Sep 2013 11:41:16 -0400
Steven Rostedt wrote:
> On Mon, 9 Sep 2013 15:24:55 +
> Christoph Lameter wrote:
>
> > On Mon, 9 Sep 2013, Peter Zijlstra wrote:
> >
> > > > Slander. Certainly validation is good. Its just that PREEMPT kernels are
> > > > not in use
> > >
> > > Complete bu
* Christoph Lameter wrote:
> On Mon, 9 Sep 2013, Peter Zijlstra wrote:
>
> > > Slander. Certainly validation is good. Its just that PREEMPT kernels
> > > are not in use
> >
> > Complete bullshit, its part of the mainline kernel, lots of people run
> > them -- including me, and any patch is su
On Mon, 9 Sep 2013 11:20:57 -0400
Steven Rostedt wrote:
> > It's a bit the same with spinlocks. spinlocks aren't a task synchronization
> > but a CPU synchronization. It's low level. Of course a task can't sleep
> > with a spinlock held (not talking about -rt) so it could be defined as a per
> >
On Mon, 9 Sep 2013 15:24:55 +
Christoph Lameter wrote:
> On Mon, 9 Sep 2013, Peter Zijlstra wrote:
>
> > > Slander. Certainly validation is good. Its just that PREEMPT kernels are
> > > not in use
> >
> > Complete bullshit, its part of the mainline kernel, lots of people run
> > them -- incl
On Mon, 9 Sep 2013, Peter Zijlstra wrote:
> > Slander. Certainly validation is good. Its just that PREEMPT kernels are
> > not in use
>
> Complete bullshit, its part of the mainline kernel, lots of people run
> them -- including me, and any patch is supposed to keep it working.
Nonsense. There is
On Mon, 9 Sep 2013 16:40:38 +0200
Frederic Weisbecker wrote:
> On Mon, Sep 09, 2013 at 09:29:17AM -0400, Steven Rostedt wrote:
> > On Mon, 9 Sep 2013 09:21:42 -0400
> > Steven Rostedt wrote:
> >
> >
> > > Especially since the function name itself is "rcu_is_cpu_idle()" which
> > > tells you i
On Mon, Sep 09, 2013 at 02:49:42PM +, Christoph Lameter wrote:
> On Mon, 9 Sep 2013, Peter Zijlstra wrote:
>
> > On Mon, Sep 09, 2013 at 06:23:43AM -0700, Paul E. McKenney wrote:
> > > And guys, I have to say that the advice on which per-CPU primitive to use
> > > varies wildly and randomly.
On Mon, 9 Sep 2013, Peter Zijlstra wrote:
> On Mon, Sep 09, 2013 at 06:23:43AM -0700, Paul E. McKenney wrote:
> > And guys, I have to say that the advice on which per-CPU primitive to use
> > varies wildly and randomly. For all I know, each of you individually
> > might well be sticking to the sa
On Mon, Sep 09, 2013 at 09:29:17AM -0400, Steven Rostedt wrote:
> On Mon, 9 Sep 2013 09:21:42 -0400
> Steven Rostedt wrote:
>
>
> > Especially since the function name itself is "rcu_is_cpu_idle()" which
> > tells you it's a cpu state, and not a task state. Why would you care in
> > RCU if CPU 1
On Mon, Sep 09, 2013 at 06:23:43AM -0700, Paul E. McKenney wrote:
> Peter, in the general case, you are quite correct. But this is a special
> case where it really does work.
>
> The key point here is that preemption and migration cannot move a task
> from a CPU to which RCU is paying attention t
On Mon, 9 Sep 2013 06:56:56 -0700
"Paul E. McKenney" wrote:
> Indeed, there is on ongoing naming debate as well. About the only point
> of agreement thus far is that the current names are inadequate. ;-)
>
> My current feeling is that rcu_is_cpu_idle() should be called
> rcu_watching_this_cpu(
On Mon, Sep 09, 2013 at 03:45:06PM +0200, Frederic Weisbecker wrote:
> On Mon, Sep 09, 2013 at 09:21:42AM -0400, Steven Rostedt wrote:
> > On Mon, 9 Sep 2013 15:08:53 +0200
> > Frederic Weisbecker wrote:
> >
> > > On Mon, Sep 09, 2013 at 08:55:04AM -0400, Steven Rostedt wrote:
> >
> > > > From r
On Mon, 9 Sep 2013 06:46:05 -0700
"Paul E. McKenney" wrote:
> > Also, if its per-task, why don't we have this in the task struct? The
> > current scheme makes the context switch more expensive -- is this the
> > right trade-off?
>
> There are constraints based on the task, but RCU really is
>
On Mon, Sep 09, 2013 at 03:36:04PM +0200, Peter Zijlstra wrote:
> On Mon, Sep 09, 2013 at 06:23:43AM -0700, Paul E. McKenney wrote:
> > And guys, I have to say that the advice on which per-CPU primitive to use
> > varies wildly and randomly. For all I know, each of you individually
> > might well
On Mon, Sep 09, 2013 at 09:41:32AM -0400, Steven Rostedt wrote:
> On Mon, 9 Sep 2013 15:29:02 +0200
> Frederic Weisbecker wrote:
>
>
> > No, putting that on the task_struct won't help much in this regard I think.
> > Regular schedule() calls don't change that per cpu state.
>
> But is there a p
On Mon, Sep 09, 2013 at 09:29:17AM -0400, Steven Rostedt wrote:
> On Mon, 9 Sep 2013 09:21:42 -0400
> Steven Rostedt wrote:
>
>
> > Especially since the function name itself is "rcu_is_cpu_idle()" which
> > tells you it's a cpu state, and not a task state. Why would you care in
> > RCU if CPU 1
On Mon, Sep 09, 2013 at 09:41:32AM -0400, Steven Rostedt wrote:
> On Mon, 9 Sep 2013 15:29:02 +0200
> Frederic Weisbecker wrote:
>
>
> > No, putting that on the task_struct won't help much in this regard I think.
> > Regular schedule() calls don't change that per cpu state.
>
> But is there a
On Mon, Sep 09, 2013 at 03:14:52PM +0200, Peter Zijlstra wrote:
> On Mon, Sep 09, 2013 at 08:55:04AM -0400, Steven Rostedt wrote:
> > On Mon, 9 Sep 2013 14:45:49 +0200
> > Frederic Weisbecker wrote:
> >
> >
> > > > This just proves that the caller of rcu_is_cpu_idle() must disable
> > > > preem
On Mon, Sep 09, 2013 at 09:21:42AM -0400, Steven Rostedt wrote:
> On Mon, 9 Sep 2013 15:08:53 +0200
> Frederic Weisbecker wrote:
>
> > On Mon, Sep 09, 2013 at 08:55:04AM -0400, Steven Rostedt wrote:
>
> > > From reading the context a bit more, it seems that the per cpu value is
> > > more a "per
On Mon, 9 Sep 2013 15:29:02 +0200
Frederic Weisbecker wrote:
> No, putting that on the task_struct won't help much in this regard I think.
> Regular schedule() calls don't change that per cpu state.
But is there a place that it would need to?
I mean, if RCU is not tracking a CPU, is it safe t
On Mon, Sep 09, 2013 at 09:29:17AM -0400, Steven Rostedt wrote:
> But I believe it's easier to grab
> per cpu info in assembly today than it once was, which is why there is
> a push to move preempt_count to per_cpu where it truly belongs.
On some architectures at least. But yes, I should get back
On Mon, Sep 09, 2013 at 06:23:43AM -0700, Paul E. McKenney wrote:
> And guys, I have to say that the advice on which per-CPU primitive to use
> varies wildly and randomly. For all I know, each of you individually
> might well be sticking to the same story, but taken together, your
> collective adv
On Mon, 9 Sep 2013 06:23:43 -0700
"Paul E. McKenney" wrote:
> On Mon, Sep 09, 2013 at 12:53:47PM +0200, Peter Zijlstra wrote:
> > On Fri, Sep 06, 2013 at 08:59:29PM +0200, Frederic Weisbecker wrote:
> > > Imagine that you're running on an rcu read side critical section on CPU
> > > 0, which
> >
On Mon, 9 Sep 2013 09:21:42 -0400
Steven Rostedt wrote:
> Especially since the function name itself is "rcu_is_cpu_idle()" which
> tells you it's a cpu state, and not a task state. Why would you care in
> RCU if CPU 1 is idle if you are on CPU 2? The name should be changed.
> Actually, preempt
On Mon, Sep 09, 2013 at 09:21:42AM -0400, Steven Rostedt wrote:
> On Mon, 9 Sep 2013 15:08:53 +0200
> Frederic Weisbecker wrote:
>
> > On Mon, Sep 09, 2013 at 08:55:04AM -0400, Steven Rostedt wrote:
>
> > > From reading the context a bit more, it seems that the per cpu value is
> > > more a "per
On Mon, Sep 09, 2013 at 03:14:52PM +0200, Peter Zijlstra wrote:
> On Mon, Sep 09, 2013 at 08:55:04AM -0400, Steven Rostedt wrote:
> > On Mon, 9 Sep 2013 14:45:49 +0200
> > Frederic Weisbecker wrote:
> >
> >
> > > > This just proves that the caller of rcu_is_cpu_idle() must disable
> > > > preem
On Mon, Sep 09, 2013 at 12:53:47PM +0200, Peter Zijlstra wrote:
> On Fri, Sep 06, 2013 at 08:59:29PM +0200, Frederic Weisbecker wrote:
> > Imagine that you're running on an rcu read side critical section on CPU 0,
> > which
> > is not in extended quiescent state. Now you get preempted in the middl
On Mon, 9 Sep 2013 15:08:53 +0200
Frederic Weisbecker wrote:
> On Mon, Sep 09, 2013 at 08:55:04AM -0400, Steven Rostedt wrote:
> > From reading the context a bit more, it seems that the per cpu value is
> > more a "per task" value that happens to be using per cpu variables, and
> > changes on co
On Mon, Sep 09, 2013 at 08:55:04AM -0400, Steven Rostedt wrote:
> On Mon, 9 Sep 2013 14:45:49 +0200
> Frederic Weisbecker wrote:
>
>
> > > This just proves that the caller of rcu_is_cpu_idle() must disable
> > > preemption itself for the entire time that it needs to use the result
> > > of rcu_
On Mon, Sep 09, 2013 at 08:55:04AM -0400, Steven Rostedt wrote:
> On Mon, 9 Sep 2013 14:45:49 +0200
> Frederic Weisbecker wrote:
>
>
> > > This just proves that the caller of rcu_is_cpu_idle() must disable
> > > preemption itself for the entire time that it needs to use the result
> > > of rcu_
On Mon, 9 Sep 2013 14:45:49 +0200
Frederic Weisbecker wrote:
> > This just proves that the caller of rcu_is_cpu_idle() must disable
> > preemption itself for the entire time that it needs to use the result
> > of rcu_is_cpu_idle().
>
> Sorry, I don't understand your point here. What's wrong wi
On Mon, Sep 09, 2013 at 08:39:26AM -0400, Steven Rostedt wrote:
> On Mon, 9 Sep 2013 14:13:31 +0200
> Frederic Weisbecker wrote:
>
>
> > > In any case the preempt_disable/enable pair there is just plain wrong as
> > > Eric pointed out.
> >
> > Check this:
> >
> > 34240697d619c439c55f2198968002
On Mon, 9 Sep 2013 14:13:31 +0200
Frederic Weisbecker wrote:
> > In any case the preempt_disable/enable pair there is just plain wrong as
> > Eric pointed out.
>
> Check this:
>
> 34240697d619c439c55f21989680024dcb604aab "rcu: Disable preemption in
> rcu_is_cpu_idle()"
Ug, and that patch do
On Mon, Sep 09, 2013 at 12:53:47PM +0200, Peter Zijlstra wrote:
> On Fri, Sep 06, 2013 at 08:59:29PM +0200, Frederic Weisbecker wrote:
> > Imagine that you're running on an rcu read side critical section on CPU 0,
> > which
> > is not in extended quiescent state. Now you get preempted in the middl
On Fri, Sep 06, 2013 at 10:52:38AM -0700, Paul E. McKenney wrote:
> How about if I made rcu_is_cpu_idle() be as follows?
>
> int rcu_is_cpu_idle(void)
> {
> int ret;
>
> ret = (atomic_read(&per_cpu(rcu_dynticks.dynticks,
> raw_smp_processor_id())) & 0
On Fri, Sep 06, 2013 at 08:59:29PM +0200, Frederic Weisbecker wrote:
> Imagine that you're running on an rcu read side critical section on CPU 0,
> which
> is not in extended quiescent state. Now you get preempted in the middle of
> your
> RCU read side critical section (you called rcu_read_lock(
On Fri, Sep 06, 2013 at 09:19:30PM -0400, Mathieu Desnoyers wrote:
> * Paul E. McKenney (paul...@linux.vnet.ibm.com) wrote:
> > On Fri, Sep 06, 2013 at 02:21:35PM -0400, Steven Rostedt wrote:
> > > On Fri, 6 Sep 2013 10:52:38 -0700
> > > "Paul E. McKenney" wrote:
> > >
> > > > > What exactly does
* Paul E. McKenney (paul...@linux.vnet.ibm.com) wrote:
> On Fri, Sep 06, 2013 at 02:21:35PM -0400, Steven Rostedt wrote:
> > On Fri, 6 Sep 2013 10:52:38 -0700
> > "Paul E. McKenney" wrote:
> >
> > > > What exactly does "extended quiescent state" mean? (Note, that's a
> > > > rhetorical question)
On Fri, Sep 06, 2013 at 02:21:35PM -0400, Steven Rostedt wrote:
> On Fri, 6 Sep 2013 10:52:38 -0700
> "Paul E. McKenney" wrote:
>
> > > What exactly does "extended quiescent state" mean? (Note, that's a
> > > rhetorical question)
> >
> > In which case my rhetorical (and therefore useless) answer
On Fri, Sep 06, 2013 at 08:59:29PM +0200, Frederic Weisbecker wrote:
> On Fri, Sep 06, 2013 at 10:41:17AM -0700, Paul E. McKenney wrote:
> > On Fri, Sep 06, 2013 at 10:21:28AM -0700, Eric Dumazet wrote:
> > > On Fri, 2013-09-06 at 08:18 -0700, Paul E. McKenney wrote:
> > >
> > > > int rcu_is_cpu_i
On Fri, Sep 06, 2013 at 10:41:17AM -0700, Paul E. McKenney wrote:
> On Fri, Sep 06, 2013 at 10:21:28AM -0700, Eric Dumazet wrote:
> > On Fri, 2013-09-06 at 08:18 -0700, Paul E. McKenney wrote:
> >
> > > int rcu_is_cpu_idle(void)
> > > {
> > > int ret;
> > >
> > > preempt_disable();
> > > re
On Fri, 6 Sep 2013 10:52:38 -0700
"Paul E. McKenney" wrote:
> > What exactly does "extended quiescent state" mean? (Note, that's a
> > rhetorical question)
>
> In which case my rhetorical (and therefore useless) answer has to be
> "it is a quiescent state that is extended". ;-)
>
> Sorry, cou
On Fri, Sep 06, 2013 at 10:52:38AM -0700, Paul E. McKenney wrote:
> On Fri, Sep 06, 2013 at 01:16:31PM -0400, Steven Rostedt wrote:
> > On Fri, 6 Sep 2013 19:00:08 +0200
> > Frederic Weisbecker wrote:
> >
> > > On Fri, Sep 06, 2013 at 12:52:38PM -0400, Steven Rostedt wrote:
> > > > On Fri, 6 Sep
On Fri, Sep 06, 2013 at 01:16:31PM -0400, Steven Rostedt wrote:
> On Fri, 6 Sep 2013 19:00:08 +0200
> Frederic Weisbecker wrote:
>
> > On Fri, Sep 06, 2013 at 12:52:38PM -0400, Steven Rostedt wrote:
> > > On Fri, 6 Sep 2013 18:40:18 +0200
> > > Frederic Weisbecker wrote:
> > >
> > > > > I can'
On Fri, Sep 06, 2013 at 10:21:28AM -0700, Eric Dumazet wrote:
> On Fri, 2013-09-06 at 08:18 -0700, Paul E. McKenney wrote:
>
> > int rcu_is_cpu_idle(void)
> > {
> > int ret;
> >
> > preempt_disable();
> > ret = (atomic_read(&__get_cpu_var(rcu_dynticks).dynticks) & 0x1) == 0;
> > p
On Fri, Sep 06, 2013 at 12:52:38PM -0400, Steven Rostedt wrote:
> On Fri, 6 Sep 2013 18:40:18 +0200
> Frederic Weisbecker wrote:
>
> > > I can't use plain preempt_disable() in function tracing.
> > >
> > > Also, since it's a misnomer to say the cpu is idle in NO_HZ_FULL when
> > > we are coming
On Fri, 6 Sep 2013 19:00:08 +0200
Frederic Weisbecker wrote:
> On Fri, Sep 06, 2013 at 12:52:38PM -0400, Steven Rostedt wrote:
> > On Fri, 6 Sep 2013 18:40:18 +0200
> > Frederic Weisbecker wrote:
> >
> > > > I can't use plain preempt_disable() in function tracing.
> > > >
> > > > Also, since
On Fri, 2013-09-06 at 08:18 -0700, Paul E. McKenney wrote:
> int rcu_is_cpu_idle(void)
> {
> int ret;
>
> preempt_disable();
> ret = (atomic_read(&__get_cpu_var(rcu_dynticks).dynticks) & 0x1) == 0;
> preempt_enable();
> return ret;
> }
Paul I find this very confusin
On Fri, 6 Sep 2013 18:40:18 +0200
Frederic Weisbecker wrote:
> > I can't use plain preempt_disable() in function tracing.
> >
> > Also, since it's a misnomer to say the cpu is idle in NO_HZ_FULL when
> > we are coming from userspace, can we rename that?
> >
> > Perhaps we can also have a __rcu
On Fri, Sep 06, 2013 at 12:52:38PM -0400, Steven Rostedt wrote:
> On Fri, 6 Sep 2013 18:40:18 +0200
> Frederic Weisbecker wrote:
>
> > > I can't use plain preempt_disable() in function tracing.
> > >
> > > Also, since it's a misnomer to say the cpu is idle in NO_HZ_FULL when
> > > we are coming
On Fri, Sep 06, 2013 at 11:33:20AM -0400, Steven Rostedt wrote:
> On Fri, 6 Sep 2013 08:18:52 -0700
> "Paul E. McKenney" wrote:
>
> > On Fri, Sep 06, 2013 at 12:59:41PM +0200, Frederic Weisbecker wrote:
> > > On Thu, Sep 05, 2013 at 12:52:34PM -0700, Paul E. McKenney wrote:
> > > > There is curre
On Fri, 6 Sep 2013 08:18:52 -0700
"Paul E. McKenney" wrote:
> On Fri, Sep 06, 2013 at 12:59:41PM +0200, Frederic Weisbecker wrote:
> > On Thu, Sep 05, 2013 at 12:52:34PM -0700, Paul E. McKenney wrote:
> > > There is currently no way for kernel code to determine whether it
> > > is safe to enter a
On Fri, Sep 06, 2013 at 12:59:41PM +0200, Frederic Weisbecker wrote:
> On Thu, Sep 05, 2013 at 12:52:34PM -0700, Paul E. McKenney wrote:
> > There is currently no way for kernel code to determine whether it
> > is safe to enter an RCU read-side critical section, in other words,
> > whether or not R
On Thu, Sep 05, 2013 at 12:52:34PM -0700, Paul E. McKenney wrote:
> There is currently no way for kernel code to determine whether it
> is safe to enter an RCU read-side critical section, in other words,
> whether or not RCU is paying attention to the currently running CPU.
> Given the large and in
On Thu, 5 Sep 2013 14:05:37 -0700
"Paul E. McKenney" wrote:
>
> rcu: Is it safe to enter an RCU read-side critical section?
>
> There is currently no way for kernel code to determine whether it
> is safe to enter an RCU read-side critical section, in other words,
Shouldn't that be a semi-colo
On Thu, Sep 05, 2013 at 04:25:58PM -0400, Steven Rostedt wrote:
> On Thu, 5 Sep 2013 12:52:34 -0700
> "Paul E. McKenney" wrote:
>
> > There is currently no way for kernel code to determine whether it
> > is safe to enter an RCU read-side critical section, in other words,
> > whether or not RCU is
On Thu, Sep 05, 2013 at 01:59:59PM -0700, Paul E. McKenney wrote:
> On Thu, Sep 05, 2013 at 04:25:58PM -0400, Steven Rostedt wrote:
> > On Thu, 5 Sep 2013 12:52:34 -0700
> > "Paul E. McKenney" wrote:
> >
> > > There is currently no way for kernel code to determine whether it
> > > is safe to ente
On Thu, 5 Sep 2013 12:52:34 -0700
"Paul E. McKenney" wrote:
> There is currently no way for kernel code to determine whether it
> is safe to enter an RCU read-side critical section, in other words,
> whether or not RCU is paying attention to the currently running CPU.
> Given the large and increa
There is currently no way for kernel code to determine whether it
is safe to enter an RCU read-side critical section, in other words,
whether or not RCU is paying attention to the currently running CPU.
Given the large and increasing quantity of code shared by the idle loop
and non-idle code, the t
98 matches
Mail list logo
