On Wed, Oct 24, 2012 at 12:50:33PM -0700, Sergey Senozhatsky wrote:
> On (10/24/12 12:41), Paul E. McKenney wrote:
> > On Wed, Oct 24, 2012 at 12:17:16PM -0700, Sergey Senozhatsky wrote:
> > > On (10/24/12 20:52), Oleg Nesterov wrote:
> > > > On 1
On Wed, Oct 24, 2012 at 04:22:17PM -0400, Mikulas Patocka wrote:
>
>
> On Wed, 24 Oct 2012, Paul E. McKenney wrote:
>
> > On Tue, Oct 23, 2012 at 05:39:43PM -0400, Mikulas Patocka wrote:
> > >
> > >
> > > On Tue, 23 Oct 2012, Paul E. McKenney wro
On Wed, Oct 24, 2012 at 04:44:14PM -0400, Mikulas Patocka wrote:
>
>
> On Wed, 24 Oct 2012, Paul E. McKenney wrote:
>
> > On Wed, Oct 24, 2012 at 04:22:17PM -0400, Mikulas Patocka wrote:
> > >
> > >
> > > On Wed, 24 Oct 2012, Paul E. McKenney wro
On Wed, Oct 24, 2012 at 04:57:35PM -0700, Paul E. McKenney wrote:
> On Wed, Oct 24, 2012 at 04:44:14PM -0400, Mikulas Patocka wrote:
> >
> >
> > On Wed, 24 Oct 2012, Paul E. McKenney wrote:
> >
> > > On Wed, Oct 24, 2012 at 04:22:17PM -0400, Mikulas Patocka
On Thu, Oct 25, 2012 at 10:54:11AM -0400, Mikulas Patocka wrote:
>
>
> On Wed, 24 Oct 2012, Paul E. McKenney wrote:
>
> > On Mon, Oct 22, 2012 at 07:39:16PM -0400, Mikulas Patocka wrote:
> > > Use rcu_read_lock_sched / rcu_read_unlock_sched / synchronize_sched
>
te()" function.
In short, I believe that wakeme_after_rcu() needs to stick around.
A better comment for wakeme_after_rcu() would be good, perhaps as shown below.
Thanx, Paul
Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
---
rcupdate
But I am concerned about the following case:
rcu_assign_pointer(global_index, 0);
. . .
x = global_array[rcu_dereference(global_index)];
Since arrays have a zero-th element, we would really want a memory
barrier in this case.
So how about leaving the index-unfriendly version of rcu_assign_poin
ely broken implementations of
rcu_assign_pointer(), I took the precaution of generating a full set of
test cases and verified that memory barriers and compiler warnings were
emitted when required. I guess it is the simple things that get you...
Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
ff-by: Paul E. McKenney <[EMAIL PROTECTED]>
---
rcupdate.h | 18 ++
1 file changed, 18 insertions(+)
diff -urpNa -X dontdiff linux-2.6.24-rap/include/linux/rcupdate.h
linux-2.6.24-rai/include/linux/rcupdate.h
--- linux-2.6.24-rap/include/linux/rcupdate.h 2008-02-13 13:36:4
On Tue, Feb 12, 2008 at 06:35:21PM -0800, Andrew Morton wrote:
> On Tue, 12 Feb 2008 16:50:45 -0800 Stephen Hemminger <[EMAIL PROTECTED]>
> wrote:
>
> > +/**
> > + * hlist_for_each_entry_continue_rcu - iterate over rcu hlist after
> > current point
> > + * @tpos: the type * to use as a loop cur
On Tue, Feb 12, 2008 at 08:46:30PM +0100, Jarek Poplawski wrote:
> On Tue, Feb 12, 2008 at 08:32:18PM +0100, Jarek Poplawski wrote:
> ...
> > It seems the above version of this macro uses the barrier for 0, but
> > if I miss something, or for these other: documenting reasons,
>
> ...or __builtin_c
On Wed, Feb 13, 2008 at 02:35:37PM -0800, Stephen Hemminger wrote:
> On Wed, 13 Feb 2008 14:00:24 -0800
> "Paul E. McKenney" <[EMAIL PROTECTED]> wrote:
>
> > Hello!
> >
> > This is an updated version of the patch posted last November:
>
On Wed, Feb 13, 2008 at 02:42:33PM -0800, Stephen Hemminger wrote:
> On Wed, 13 Feb 2008 14:41:34 -0800
> "Paul E. McKenney" <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Feb 13, 2008 at 02:35:37PM -0800, Stephen Hemminger wrote:
> > > On Wed, 13 Feb 200
On Wed, Feb 13, 2008 at 03:51:58PM -0800, Stephen Hemminger wrote:
> On Wed, 13 Feb 2008 15:37:44 -0800
> "Paul E. McKenney" <[EMAIL PROTECTED]> wrote:
> > On Wed, Feb 13, 2008 at 02:42:33PM -0800, Stephen Hemminger wrote:
> > > On Wed, 13 Feb 2008 14:41:34 -
On Wed, Feb 13, 2008 at 04:27:00PM -0800, Stephen Hemminger wrote:
> On Wed, 13 Feb 2008 16:14:04 -0800
> "Paul E. McKenney" <[EMAIL PROTECTED]> wrote:
> > On Wed, Feb 13, 2008 at 03:51:58PM -0800, Stephen Hemminger wrote:
[ . . . ]
> > > Maybe c
On Wed, Feb 13, 2008 at 04:53:56PM -0800, Stephen Hemminger wrote:
> On Wed, 13 Feb 2008 16:42:53 -0800
> "Paul E. McKenney" <[EMAIL PROTECTED]> wrote:
> > On Wed, Feb 13, 2008 at 04:27:00PM -0800, Stephen Hemminger wrote:
[ . . . ]
> > > That is heading
On Thu, Feb 14, 2008 at 09:02:09AM +0530, Gautham R Shenoy wrote:
> On Wed, Feb 13, 2008 at 02:05:15PM -0800, Paul E. McKenney wrote:
> > Hello again!
> >
> > This is a speculative patch that as far as I can tell is not yet required.
> > If anyone applies RCU to a data
On Thu, Feb 14, 2008 at 09:24:27AM -0800, Randy Dunlap wrote:
> On Wed, 13 Feb 2008 14:05:15 -0800 Paul E. McKenney wrote:
>
> > Hello again!
> >
> > This is a speculative patch that as far as I can tell is not yet required.
> > If anyone applies RCU to a data struc
on as the
> kernel they are for.
Good catch, and works fine here against 2.6.25-rc1. Andrew, Linus,
could you please apply this?
Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
> Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
> ---
> include/linux/rcupdate.h |2
On Fri, Feb 15, 2008 at 04:40:24PM -0800, Andrew Morton wrote:
> On Wed, 13 Feb 2008 14:00:24 -0800
> "Paul E. McKenney" <[EMAIL PROTECTED]> wrote:
>
> > Hello!
> >
> > This is an updated version of the patch posted last November:
> >
> >
On Sat, Feb 16, 2008 at 10:47:23AM +0200, Adrian Bunk wrote:
> On Mon, Jan 28, 2008 at 04:25:00AM -0800, Paul E. McKenney wrote:
> > Hello!
> >
> > The list_for_each_entry_rcu() primitive should be used instead of
> > list_for_each_rcu(), as the former is easier to
On Wed, Oct 31, 2012 at 07:23:03PM +0800, Shan Wei wrote:
> From: Shan Wei
>
> smp_processor_id is defined as raw_smp_processor_id.
> replace per_cpu_ptr(p, raw_smp_processor_id()) is also ok.
>
> Signed-off-by: Shan Wei
Hello, Shan Wei,
There are several definitions of this_cpu_ptr():
0 per
On Wed, Oct 31, 2012 at 09:20:19PM +0800, Shan Wei wrote:
> Paul E. McKenney said, at 2012/10/31 19:51:
> >
> > The first uses smp_processor_id(), which will complain if
> > force_quiescent_state() is called with preemption disabled, which it
> > sometimes is.
> &g
On Wed, Oct 31, 2012 at 05:47:04PM +, Christoph Lameter wrote:
> On Wed, 31 Oct 2012, Shan Wei wrote:
>
> > Signed-off-by: Shan Wei
> > ---
> > kernel/rcutree.c |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/kernel/rcutree.c b/kernel/rcutree.c
> > index
On Wed, Oct 31, 2012 at 08:41:58PM +0100, Oleg Nesterov wrote:
> Currently the writer does msleep() plus synchronize_sched() 3 times
> to acquire/release the semaphore, and during this time the readers
> are blocked completely. Even if the "write" section was not actually
> started or if it was alr
On Sat, Nov 03, 2012 at 12:01:47AM +0800, Shan Wei wrote:
> From: Shan Wei
>
> Signed-off-by: Shan Wei
> ---
> kernel/rcutree.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/kernel/rcutree.c b/kernel/rcutree.c
> index 74df86b..441b945 100644
> --- a/kernel/rcut
On Fri, Nov 02, 2012 at 03:03:01PM +, Christoph Lameter wrote:
> On Fri, 2 Nov 2012, Steven Rostedt wrote:
>
> > > also it would be best to sync this conceptually with the processors
> > > enabled for rcu processing.
> >
> > Processors can be disabled for rcu processing? Or are you talking abo
On Wed, Oct 31, 2012 at 03:10:04PM +0100, Frederic Weisbecker wrote:
> 2012/10/31 Paul E. McKenney :
> > +/*
> > + * Per-rcu_data kthread, but only for no-CBs CPUs. Each kthread invokes
> > + * callbacks queued by the corresponding no-CBs CPU.
> > + */
> > +stat
On Fri, Nov 02, 2012 at 08:16:58PM +, Christoph Lameter wrote:
> On Fri, 2 Nov 2012, Paul E. McKenney wrote:
>
> > So I believe that these need to be controlled separately for the immediate
> > future.
>
> Yes they do but the configurations are similar and it would
On Fri, Nov 02, 2012 at 04:51:50PM -0400, Steven Rostedt wrote:
> On Fri, 2012-11-02 at 13:41 -0700, Paul E. McKenney wrote:
>
> > The no-CBs mask would be read-only for some time -- changed only at
> > boot. Longer term, I hope to allow run-time modification, but...
>
&
On Fri, Nov 02, 2012 at 08:19:04PM +, Christoph Lameter wrote:
> On Fri, 2 Nov 2012, Paul E. McKenney wrote:
>
> > On Sat, Nov 03, 2012 at 12:01:47AM +0800, Shan Wei wrote:
> > > From: Shan Wei
> > >
> > > Signed-off-by: Shan Wei
> > > ---
. Meaning that we should not be relying on pure testing to find
places where people are relying on preemption disabling to block CPUs
from going offline. ;-)
Not-yet-signed-off-by: Paul E. McKenney
diff --git a/kernel/cpu.c b/kernel/cpu.c
index a4eb522..47e63a0 100644
--- a/kernel/cpu.c
+++ b
On Fri, Jul 27, 2012 at 05:40:30PM +0200, Frederic Weisbecker wrote:
> Create a new subsystem that handles the hooks on kernel/user
> boundaries currently used by RCU for its userspace extended
> quiescent state.
>
> We need to pull this up from RCU into this new level of indirection
> because the
On Fri, Jul 27, 2012 at 12:22:46PM -0700, Hugh Dickins wrote:
> On Thu, 26 Jul 2012, Peter Zijlstra wrote:
> > On Tue, 2012-07-24 at 14:51 -0700, Hugh Dickins wrote:
> > > I do love the status quo, but an audit would be welcome. When
> > > it comes to patches, personally I tend to prefer ACCESS_ON
d() to pr->id, as is
> used elsewhere in the code, for example, in acpi_processor_add().
>
> Signed-off-by: Paul E. McKenney
>
> diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
> index 0e8e2de..9e57b06 100644
> --- a/drivers/acpi/proce
On Sun, Jul 29, 2012 at 01:13:34AM -0400, Mikulas Patocka wrote:
> On Sat, 28 Jul 2012, Eric Dumazet wrote:
> > On Sat, 2012-07-28 at 12:41 -0400, Mikulas Patocka wrote:
[ . . . ]
> > (bdev->bd_block_size should be read exactly once )
>
> Rewrite all direct and non-direct io code so that it read
On Mon, Jul 30, 2012 at 11:07:47PM +0800, Feng Tang wrote:
> Hi Paul,
>
> On Mon, 30 Jul 2012 06:39:13 -0700
> "Paul E. McKenney" wrote:
>
> > On Mon, Jul 30, 2012 at 03:15:59PM +0800, Feng Tang wrote:
> > > Hi All,
> > >
> &g
On Mon, Jul 30, 2012 at 10:08:47AM -0700, Paul E. McKenney wrote:
> On Mon, Jul 30, 2012 at 11:07:47PM +0800, Feng Tang wrote:
> > Hi Paul,
> >
> > On Mon, 30 Jul 2012 06:39:13 -0700
> > "Paul E. McKenney" wrote:
> >
> > > On Mon, Jul 30, 2
On Mon, Jul 30, 2012 at 08:21:40PM +0100, Jamie Lokier wrote:
> Paul E. McKenney wrote:
> > > Does some version of gcc, under the options which we insist upon,
> > > make such optimizations on any of the architectures which we support?
> >
> > Pretty much any pr
On Tue, Jul 31, 2012 at 11:18:32AM +0800, Feng Tang wrote:
> Hi Paul,
>
> On Mon, 30 Jul 2012 10:42:18 -0700
> "Paul E. McKenney" wrote:
>
> > On Mon, Jul 30, 2012 at 10:08:47AM -0700, Paul E. McKenney wrote:
> > > On Mon, Jul 30, 2012 at 11:07:47PM
On Tue, Jul 31, 2012 at 09:44:13AM -0400, Steven Rostedt wrote:
> On Tue, 2012-07-31 at 20:10 +0800, Fengguang Wu wrote:
>
> > Another note: the above __update_max_tr back trace only appear accasionally.
> > The more typical error messages look like this:
> >
> > [ 16.195315] Running tests on t
On Tue, Jul 31, 2012 at 09:33:45AM -0400, Steven Rostedt wrote:
> On Tue, 2012-07-31 at 20:05 +0800, Fengguang Wu wrote:
> > On Mon, Jul 30, 2012 at 11:39:12AM -0400, Steven Rostedt wrote:
> > > On Tue, 2012-07-24 at 17:03 +0800, Fengguang Wu wrote:
> > > > Hi Steven,
> > >
> > > Hi Fengguang,
> >
On Tue, Jul 31, 2012 at 10:51:51AM -0400, Steven Rostedt wrote:
> On Tue, 2012-07-31 at 07:44 -0700, Paul E. McKenney wrote:
>
> > > Found it (and Cc'd David).
> > >
> > > In __update_max_tr() we have:
> > >
> > > ma
On Tue, Jul 31, 2012 at 10:56:23AM -0400, Steven Rostedt wrote:
> On Tue, 2012-07-31 at 10:51 -0400, Steven Rostedt wrote:
>
> > > OK, I will bite. How about using something like RCU_NONIDLE(), either
> > > directly or open-coded, to make it a legal call site?
> >
> > OK, then something like:
>
On Tue, Jul 31, 2012 at 11:45:02AM -0400, Steven Rostedt wrote:
> On Tue, 2012-07-31 at 08:18 -0700, Paul E. McKenney wrote:
> > On Tue, Jul 31, 2012 at 10:56:23AM -0400, Steven Rostedt wrote:
> > > On Tue, 2012-07-31 at 10:51 -0400, Steven Rostedt wrote:
> > >
>
On Tue, Jul 31, 2012 at 01:24:57PM -0400, Steven Rostedt wrote:
> On Tue, 2012-07-31 at 10:17 -0700, Paul E. McKenney wrote:
>
> > rcu: Permit RCU_NONIDLE() to be used from interrupt context
> >
> > There is a need to use RCU from interrupt context, but either befor
On Tue, Jul 31, 2012 at 02:06:41PM -0400, Steven Rostedt wrote:
> On Tue, 2012-07-31 at 10:44 -0700, Paul E. McKenney wrote:
>
> > OK, I interpret this as excluding NMI handlers, but please let me
> > know if I am still being naive. ;-)
> >
>
> You are corr
dynticks_nesting, which may indicate RCU is in an extended quiescent
> state.
Thank you, Zhong. Queued, as those checking the SOBs below might
guess. ;-)
Thanx, paul
> Signed-off-by: Li Zhong
> Signed-off-by: Paul E. McKenney
On Fri, Sep 21, 2012 at 11:30:33AM +0200, Sasha Levin wrote:
> On 09/20/2012 05:23 PM, Paul E. McKenney wrote:
> > On Thu, Sep 20, 2012 at 09:44:57AM +0200, Sasha Levin wrote:
> >> On 09/20/2012 09:33 AM, Michael Wang wrote:
> >>> On 09/20/2012 01:06 AM, Paul E. McKe
On Fri, Sep 21, 2012 at 03:26:27PM +0200, Sasha Levin wrote:
> On 09/21/2012 02:13 PM, Paul E. McKenney wrote:
> >> This might be unrelated, but I got the following dump as well when trinity
> >> > decided it's time to reboot my guest:
> > OK, sounds like we
On Fri, Sep 21, 2012 at 06:08:59PM +, Paul Walmsley wrote:
> cc Frederic Weisbecker - context is here:
>
>http://marc.info/?l=linux-kernel&m=134749030206016&w=2
>
> On Thu, 20 Sep 2012, Paul E. McKenney wrote:
>
> > Fair point. I am wondering whether
On Fri, Sep 21, 2012 at 07:11:14PM +, Paul Walmsley wrote:
> On Fri, 21 Sep 2012, Paul E. McKenney wrote:
>
> > On Fri, Sep 21, 2012 at 06:08:59PM +, Paul Walmsley wrote:
> >
> > > As far as I know, our only idle entry point is in
> > > arch/arm/comm
On Fri, Sep 21, 2012 at 05:47:31PM +, Paul Walmsley wrote:
> Hi Paul
>
> On Thu, 20 Sep 2012, Paul Walmsley wrote:
>
> > On Thu, 20 Sep 2012, Paul E. McKenney wrote:
> >
> > > Paul Walmsley, please let me know if the config below doesn't clear thing
On Fri, Sep 21, 2012 at 01:31:49PM -0700, Tony Lindgren wrote:
> * Paul E. McKenney [120921 12:58]:
> >
> > Just to make sure I understand the combinations:
> >
> > o All stalls have happened when running a minimal userspace.
> > o CONFIG_NO_
e the
> unsigned long equivalent instead, "timer=4294967295". This is what
> actually shows up in traces.
>
> Signed-off-by: Paul Walmsley
> Cc: Paul E. McKenney
> Cc: Dipankar Sarma
Good catch! Even worse, it gives "timer=18446744073709551615" on
64-bit
On Fri, Sep 21, 2012 at 12:57:17PM -0700, Paul E. McKenney wrote:
> On Fri, Sep 21, 2012 at 07:11:14PM +, Paul Walmsley wrote:
> > On Fri, 21 Sep 2012, Paul E. McKenney wrote:
[ . . . ]
> > > I may take your advice of remote access to a Panda board, though that
> > &
On Fri, Sep 21, 2012 at 10:41:14PM +, Paul Walmsley wrote:
> On Fri, 21 Sep 2012, Paul E. McKenney wrote:
>
> > On Fri, Sep 21, 2012 at 05:47:31PM +, Paul Walmsley wrote:
> >
> > > I built an OMAP kernel from Linus' commit
> > > 4651afbbae9687
On Sat, Sep 22, 2012 at 10:26:09AM +0200, Sasha Levin wrote:
> On 09/21/2012 05:18 PM, Sasha Levin wrote:
> > On 09/21/2012 05:12 PM, Paul E. McKenney wrote:
> >> On Fri, Sep 21, 2012 at 03:26:27PM +0200, Sasha Levin wrote:
> >>> On 09/21/2012 02:13 PM, Paul E. McKe
On Sat, Sep 22, 2012 at 08:09:13AM -0700, Paul E. McKenney wrote:
> On Sat, Sep 22, 2012 at 10:26:09AM +0200, Sasha Levin wrote:
> > On 09/21/2012 05:18 PM, Sasha Levin wrote:
> > > On 09/21/2012 05:12 PM, Paul E. McKenney wrote:
> > >> On Fri, Sep 21, 2012 at 03:26
On Sat, Sep 22, 2012 at 05:45:12PM +0200, Frederic Weisbecker wrote:
> 2012/9/22 Paul E. McKenney :
> > On Fri, Sep 21, 2012 at 01:31:49PM -0700, Tony Lindgren wrote:
> >> * Paul E. McKenney [120921 12:58]:
> >> >
> >> > Just to make sure I understa
On Sat, Sep 22, 2012 at 06:42:08PM +, Paul Walmsley wrote:
> On Fri, 21 Sep 2012, Paul E. McKenney wrote:
>
> > Could you please point me to a recipe for creating a minimal userspace?
> > Just in case it is the userspac erather than the architecture/hardware
> > t
On Sat, Sep 22, 2012 at 06:16:15PM +, Paul Walmsley wrote:
> Hi Paul
>
> On Fri, 21 Sep 2012, Paul E. McKenney wrote:
>
> > I am wondering if your system somehow figured out how to start a grace
> > period that had no RCU callbacks waiting for it. If that happened,
&
On Sat, Sep 22, 2012 at 07:50:29PM +0200, Sasha Levin wrote:
> On 09/22/2012 05:56 PM, Paul E. McKenney wrote:
> > And now the prime suspect is the new CONFIG_RCU_USER_QS=y. Do these
> > warnings ever show up with CONFIG_RCU_USER_QS=n?
>
> It seems that disabling that does
On Sat, Sep 22, 2012 at 01:10:43PM -0700, Paul E. McKenney wrote:
> On Sat, Sep 22, 2012 at 06:42:08PM +, Paul Walmsley wrote:
> > On Fri, 21 Sep 2012, Paul E. McKenney wrote:
> >
> > > Could you please point me to a recipe for creating a minimal userspace?
>
On Sat, Sep 22, 2012 at 10:25:59PM +, Paul Walmsley wrote:
> On Sat, 22 Sep 2012, Paul E. McKenney wrote:
>
> > And here is a patch. I am still having trouble reproducing the problem,
> > but figured that I should avoid serializing things.
>
> Thanks, testing thi
On Sat, Sep 22, 2012 at 10:20:19PM +, Paul Walmsley wrote:
> Hi Paul
>
> On Sat, 22 Sep 2012, Paul E. McKenney wrote:
>
> > Strangely enough, I believe that I have inadvertently fixed this in
> > my -rcu tree:
> >
> > git://git.kernel.org/pub/scm/linux/
On Sat, Sep 22, 2012 at 02:27:35PM -0700, Paul E. McKenney wrote:
> On Sat, Sep 22, 2012 at 07:50:29PM +0200, Sasha Levin wrote:
> > On 09/22/2012 05:56 PM, Paul E. McKenney wrote:
> > > And now the prime suspect is the new CONFIG_RCU_USER_QS=y. Do these
> > >
On Sun, Sep 23, 2012 at 01:42:10AM +, Paul Walmsley wrote:
> Hi Paul
>
> On Sat, 22 Sep 2012, Paul Walmsley wrote:
>
> > On Sat, 22 Sep 2012, Paul E. McKenney wrote:
> >
> > > And here is a patch. I am still having trouble reproducing the problem,
>
On Sun, Sep 23, 2012 at 07:55:50AM +, Paul Walmsley wrote:
> On Sat, 22 Sep 2012, Paul E. McKenney wrote:
>
> > On Sat, Sep 22, 2012 at 10:25:59PM +, Paul Walmsley wrote:
> >
> > > The recent tests here have been on Pandaboard, which is dual-CPU, but my
> &
On Mon, Sep 24, 2012 at 03:11:34PM +0530, Shilimkar, Santosh wrote:
> On Sun, Sep 23, 2012 at 3:29 AM, Paul E. McKenney
> wrote:
> > On Sat, Sep 22, 2012 at 01:10:43PM -0700, Paul E. McKenney wrote:
> >> On Sat, Sep 22, 2012 at 06:42:08PM +, Paul Walmsley wrote:
>
On Mon, Sep 24, 2012 at 09:54:00PM +, Paul Walmsley wrote:
> On Sat, 22 Sep 2012, Paul E. McKenney wrote:
>
> > On Sat, Sep 22, 2012 at 10:20:19PM +, Paul Walmsley wrote:
> > > On Sat, 22 Sep 2012, Paul E. McKenney wrote:
> > >
> > > > This thi
ace list_for_each_continue_rcu with new interface
Paul E. McKenney (46):
rcu: Move RCU grace-period initialization into a kthread
rcu: Prevent initialization-time quiescent-state race
rcu: Allow RCU grace-period initialization to be preempted
rcu: Move RCU grace-period cleanup into kthr
On Tue, Sep 25, 2012 at 01:41:18AM +0200, Frederic Weisbecker wrote:
> 2012/9/25 Frederic Weisbecker :
> > 2012/9/25 Sasha Levin :
> >> On 09/25/2012 01:06 AM, Frederic Weisbecker wrote:
> >>> 2012/9/25 Sasha Levin :
> On 09/25/2012 12:47 AM, Sasha Levin wrote:
> > - While I no longer see
On Tue, Sep 25, 2012 at 01:59:26PM +0200, Frederic Weisbecker wrote:
> On Mon, Sep 24, 2012 at 09:04:20PM -0700, Paul E. McKenney wrote:
> > On Tue, Sep 25, 2012 at 01:41:18AM +0200, Frederic Weisbecker wrote:
> > > >
> > > > [ 1
device: matched device serio0 with
> driver atkbd
> [ 127.041308] CPA self-test:
>
> to this commit:
>
> commit 06ae115a1d551cd952d80df06eaf8b5153351875
> Author: Paul E. McKenney
> Date: Sun Aug 14 15:56:54 2011 -0700
>
> rcu: Avoid having just-onlined CPU resc
On Tue, Sep 25, 2012 at 08:28:23PM +0200, Sasha Levin wrote:
> On 09/25/2012 02:06 PM, Frederic Weisbecker wrote:
> > Sasha, sorry to burden you with more testing request.
> > Could you please try out this new branch? It includes some fixes after Wu
> > Fenguang and
> > Dan Carpenter reports (not
On Wed, Sep 26, 2012 at 12:22:37PM +0800, Fengguang Wu wrote:
> On Tue, Sep 25, 2012 at 08:07:01AM -0700, Paul E. McKenney wrote:
> > On Tue, Sep 25, 2012 at 07:19:38PM +0800, Fengguang Wu wrote:
> > > Hi Paul,
> > >
> > > I've just bisected down one RCU
ang (1):
kmemleak: Replace list_for_each_continue_rcu with new interface
Paul E. McKenney (46):
rcu: Move RCU grace-period initialization into a kthread
rcu: Prevent initialization-time quiescent-state race
rcu: Allow RCU grace-period initialization to be preempted
On Wed, Sep 26, 2012 at 04:56:55PM +0200, Frederic Weisbecker wrote:
> 2012/9/25 Paul E. McKenney :
> > On Tue, Sep 25, 2012 at 01:59:26PM +0200, Frederic Weisbecker wrote:
> >> Given that we have:
> >>
> >> rcu_irq_enter()
> >> rcu_user_exit()
On Wed, Sep 26, 2012 at 04:15:01PM +0800, Fengguang Wu wrote:
> On Tue, Sep 25, 2012 at 09:34:45PM -0700, Paul E. McKenney wrote:
> > On Wed, Sep 26, 2012 at 12:22:37PM +0800, Fengguang Wu wrote:
> > > On Tue, Sep 25, 2012 at 08:07:01AM -0700, Paul E. McKenney wrote:
> >
On Wed, Sep 26, 2012 at 05:46:13PM +0200, Frederic Weisbecker wrote:
> On Tue, Sep 25, 2012 at 11:36:54AM -0700, Paul E. McKenney wrote:
> > On Tue, Sep 25, 2012 at 08:28:23PM +0200, Sasha Levin wrote:
> > > On 09/25/2012 02:06 PM, Frederic Weisbecker wrote:
> > > > S
On Mon, Oct 29, 2012 at 11:02:13AM +0800, Michael Wang wrote:
> This patch fix the code style issue caused by:
>
> commit 622afdb3bd6288837a37bac137dfeff4e771798d
> "rcu: Optimize the 'rcudata' for RCU trace"
Queued, thank you Michael.
On Mon, Oct 29, 2012 at 12:38:45PM -0400, Vivek Goyal wrote:
> On Mon, Oct 29, 2012 at 07:15:08PM +0900, Jun'ichi Nomura wrote:
> > On 10/27/12 05:21, Vivek Goyal wrote:
> > > On Thu, Oct 25, 2012 at 06:41:11PM +0900, Jun'ichi Nomura wrote:
> > >> [PATCH] dm: stay in blk_queue_bypass until queue be
Hello!
This patch series contains documentation updates as follows:
1. Fix a broken example in memory-barriers.txt.
2. Fix a paper title in RTFP.txt. (Courtesy of Dhaval Giani.)
3. Mention kfree_rcu() in the whatisRCU.txt section covering
call_rcu(), and fix example code. (
From: "Paul E. McKenney"
This commit fixes a broken example of overlapping stores in the
Documentation/memory-barriers.txt file.
Reported-by: Nikunj A Dadhania
Signed-off-by: Paul E. McKenney
---
Documentation/memory-barriers.txt |9 +
1 files changed, 5 insert
From: "Paul E. McKenney"
The approach for mixing RCU and reference counting listed in the RCU
documentation only describes one possible approach. This approach can
result in failure on the read side, which is nice if you want fresh data,
but not so good if you want simple code. T
From: Kees Cook
Mention kfree_rcu() in the call_rcu() section. Additionally fix the
example code for list replacement that used the wrong structure element.
Signed-off-by: Kees Cook
Signed-off-by: Paul E. McKenney
---
Documentation/RCU/listRCU.txt |2 +-
Documentation/RCU
From: Dhaval Giani
Trying to go through the history of RCU (not for the weak
minded) led me to search for a non-existent paper.
Correct it to the actual reference
Signed-off-by: Dhaval Giani
Cc: Peter Zijlstra
Signed-off-by: Paul E. McKenney
---
Documentation/RCU/RTFP.txt |2 +-
1
DEFINE_SRCU()
and DEFINE_STATIC_SRCU() to allow statically declared SRCU structures,
using the new static per-CPU interfaces.
Signed-off-by: Lai Jiangshan
Signed-off-by: Paul E. McKenney
[ paulmck: Updated for __DELAYED_WORK_INITIALIZER() added argument,
fixed whitespace issue. ]
---
include
From: Lai Jiangshan
Use DEFINE_STATIC_SRCU() to simplify the rcutorture.c SRCU test code.
Signed-off-by: Lai Jiangshan
Reviewed-by: Josh Triplett
Signed-off-by: Paul E. McKenney
---
kernel/rcutorture.c | 41 ++---
1 files changed, 6 insertions(+), 35
From: Lai Jiangshan
Lai Jiangshan rewrote SRCU, so this commit ensures that he gets his
proper share of blame^Wcredit.
Signed-off-by: Lai Jiangshan
Signed-off-by: Paul E. McKenney
---
include/linux/srcu.h |2 ++
kernel/srcu.c|2 ++
2 files changed, 4 insertions(+), 0
From: "Paul E. McKenney"
Because grace-period initialization is carried out by a separate
kthread, it might happen on a different CPU than the one that
had the callback needing a grace period -- which is where the
callback acceleration needs to happen.
Fortunately, rcu_start_gp() hold
From: "Paul E. McKenney"
Several new rcutorture module parameters have been added, but are not
printed to the console at the beginning and end of tests, which makes
it difficult to reproduce a prior test. This commit therefore adds
these new module parameters to the list prin
Hello!
This patch series contains SRCU changes allowing srcu_structs to be
statically initialized. The patches are as follows:
1. Add Lai Jiangshan as author for srcu.c and srcu.h.
(Courtesy Lia Jiangshan.)
2. Export process_srcu() so that the initialization macro may
b
From: "Paul E. McKenney"
The list_for_each_continue_rcu() macro is no longer used, so this commit
removes it. The list_for_each_entry_continue_rcu() macro should be
used instead.
Signed-off-by: Paul E. McKenney
---
Documentation/RCU/checklist.txt | 17 -
Documen
From: "Paul E. McKenney"
The RCU CPU stall warning timeout has defaulted to 60 seconds for
some years, with almost no false positives. This commit therefore
reduces the default to 21 seconds, slightly shorter than the new
soft-lockup timeout.
Signed-off-by: Paul E. McKenney
From: Lai Jiangshan
Because process_srcu() will be used in DEFINE_SRCU(), which is a macro
that could be expanded pretty much anywhere, it can no longer be static.
Note that process_srcu() is still internal to srcu.h.
Signed-off-by: Lai Jiangshan
Signed-off-by: Paul E. McKenney
---
include
From: "Paul E. McKenney"
This commit explicitly states the memory-ordering properties of the
RCU grace-period primitives. Although these properties were in some
sense implied by the fundmental property of RCU ("a grace period must
wait for all pre-existing RCU read-side criti
Hello!
This patch contains fixes as follows:
1. Reinstate a grace-period acceleration that permits invoking
the first callback registered on an idle system in one grace
period rather than two. The previous version of this acceleration
was invalidated by the new grace
From: "Paul E. McKenney"
Commit 29c00b4a1d9e27 (rcu: Add event-tracing for RCU callback
invocation) added a regression in rcu_do_batch()
Under stress, RCU is supposed to allow to process all items in queue,
instead of a batch of 10 items (blimit), but an integer overflow makes
the
301 - 400 of 12324 matches
Mail list logo
