On Fri, Mar 09, 2007 at 06:18:51PM -0800, Andrew Morton wrote:
On Thu, 08 Mar 2007 21:50:29 +0100 Michal Piotrowski [EMAIL PROTECTED]
wrote:
Andrew Morton napisał(a):
Temporarily at
http://userweb.kernel.org/~akpm/2.6.21-rc3-mm1/
Will appear later at
On Sun, Mar 11, 2007 at 06:49:08PM +0100, Rafael J. Wysocki wrote:
On Saturday, 3 March 2007 18:32, Oleg Nesterov wrote:
On 03/02, Paul E. McKenney wrote:
On Sat, Mar 03, 2007 at 02:33:37AM +0300, Oleg Nesterov wrote:
On 03/02, Paul E. McKenney wrote:
One way to embed
On Sun, Mar 11, 2007 at 06:02:31PM +0100, Michal Piotrowski wrote:
On 10/03/07, Paul E. McKenney [EMAIL PROTECTED] wrote:
On Fri, Mar 09, 2007 at 06:18:51PM -0800, Andrew Morton wrote:
On Thu, 08 Mar 2007 21:50:29 +0100 Michal Piotrowski
[EMAIL PROTECTED] wrote:
Andrew Morton napisał
this rediffing
later, first want an easy-to-test and easy-to-inpect version.
Signed-off-by: Paul E. McKenney [EMAIL PROTECTED]
---
srcu.c | 42 +-
1 file changed, 37 insertions(+), 5 deletions(-)
diff -urpNa -X dontdiff linux-2.6.19-qrcu/kernel/srcu.c
On Mon, Feb 12, 2007 at 07:22:09AM +0100, Jens Axboe wrote:
On Sun, Feb 11 2007, Paul E. McKenney wrote:
This patch optimizes the quick RCU update-side fastpath, so that in the
absence of readers, synchronize_qrcu() does four non-atomic comparisons
and three memory barriers, eliminating
On Thu, Feb 15, 2007 at 12:21:58PM -0800, Carl Love wrote:
On Thu, 2007-02-15 at 15:37 +0100, Arnd Bergmann wrote:
[ . . . ]
I agree with Milton that it would be far nicer even to calculate
the value from user space, but since you say that would
violate the oprofile interface conventions,
On Mon, Mar 12, 2007 at 11:39:06PM +0100, Pavel Machek wrote:
Hi!
Looks good to me! The other kthread_should_stop() calls in
rcutorture.c should also become
kthread_should_top_check_freeze().
Why is it useful?
Because we want to avoid repeating
while
On Fri, Mar 23, 2007 at 01:43:53PM +, David Howells wrote:
[Resend - this time with a comma in the addresses, not a dot]
Lennert Buytenhek [EMAIL PROTECTED] wrote:
[ background: On ARM, SMP synchronisation does need barriers but device
synchronisation does not. The question is
On Sun, Mar 25, 2007 at 11:38:43PM +0200, Lennert Buytenhek wrote:
On Sun, Mar 25, 2007 at 02:15:42PM -0700, Paul E. McKenney wrote:
[ background: On ARM, SMP synchronisation does need barriers but device
synchronisation does not. The question is that given this, whether
mb
or by appropriate changes, I will ack.
A signal-related question for Oleg marked with Oleg.
Thanx, Paul
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
Cc: Paul E. McKenney [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED
On Tue, Feb 20, 2007 at 07:29:01PM +0100, Rafael J. Wysocki wrote:
On Tuesday, 20 February 2007 01:32, Rafael J. Wysocki wrote:
On Tuesday, 20 February 2007 01:12, Oleg Nesterov wrote:
Hm. In the case discussed above we have a task that's right before calling
frozen_process(), so we can't
On Wed, Feb 21, 2007 at 07:13:40PM +0100, Rafael J. Wysocki wrote:
On Wednesday, 21 February 2007 19:14, Paul E. McKenney wrote:
On Tue, Feb 20, 2007 at 07:29:01PM +0100, Rafael J. Wysocki wrote:
On Tuesday, 20 February 2007 01:32, Rafael J. Wysocki wrote:
On Tuesday, 20 February 2007 01
On Wed, Feb 21, 2007 at 11:03:14PM +0300, Oleg Nesterov wrote:
On 02/21, Rafael J. Wysocki wrote:
On Wednesday, 21 February 2007 19:14, Paul E. McKenney wrote:
On Tue, Feb 20, 2007 at 07:29:01PM +0100, Rafael J. Wysocki wrote:
On Tuesday, 20 February 2007 01:32, Rafael J. Wysocki wrote
On Sat, Feb 24, 2007 at 12:23:03AM +0300, Oleg Nesterov wrote:
If my understanding correct, vmscan can find a page which lives in a already
anon_vma_unlink'ed vma. This is ok, the page is pinned, and page-mapping is
not cleared until free_hot_cold_page().
So page_lock_anon_vma() works
.
For a terrified few minutes, I thought that the code assumed that struct
rcu_head was the same size as struct list_head, but it turns out to only
assume that struct slab is at least as large as struct slab_rcu.
Thanx, Paul
Signed-off-by: Paul E. McKenney
On Sat, Feb 24, 2007 at 10:10:57PM +, Hugh Dickins wrote:
On Fri, 23 Feb 2007, Paul E. McKenney wrote:
This look like a valid fix to me, at least as long as the lock is never
dropped in the meantime (e.g., to do I/O). If the lock -is- dropped in
the meantime, then presumably
Hello!
I got the following running stock 2.6.20-rt8 on an 4-CPU 1.8GHz Opteron
box. The machine continued to run a few rounds of kernbench and LTP.
Looks a bit scary -- a tasklet was stolen from __tasklet_action().
Thoughts? In the meantime, kicking it off again to see if it repeats.
On Fri, Feb 23, 2007 at 04:37:43PM +0100, Nick Piggin wrote:
The dentry hash uses up 8MB for 1 million entries on my 4GB system is one
of the biggest wasters of memory for me. Because I rarely have more than one
or
two hundred thousand dentries. And that's with several kernel trees worth of
immediately, but this would help only in case of a three-way race
between two synchronize_qrcu()s and a qrcu_read_unlock(), would add
another compare, so is not worth it.)
Signed-off-by: Paul E. McKenney [EMAIL PROTECTED]
---
include/linux/srcu.h | 22 +
kernel/srcu.c| 86
On Sat, Feb 24, 2007 at 09:02:12PM -0800, Paul E. McKenney wrote:
Hello!
I got the following running stock 2.6.20-rt8 on an 4-CPU 1.8GHz Opteron
box. The machine continued to run a few rounds of kernbench and LTP.
Looks a bit scary -- a tasklet was stolen from __tasklet_action
On Sun, Feb 25, 2007 at 11:05:50PM +0300, Oleg Nesterov wrote:
On 02/24, Hugh Dickins wrote:
On Sat, 24 Feb 2007, Oleg Nesterov wrote:
So page_lock_anon_vma() works correctly due to SLAB_DESTROY_BY_RCU even if
anon_vma_unlink() has already freed anon_vma. In that case we should see
On Sun, Feb 25, 2007 at 07:27:47AM +0100, Ingo Molnar wrote:
* Paul E. McKenney [EMAIL PROTECTED] wrote:
I got the following running stock 2.6.20-rt8 on an 4-CPU 1.8GHz
Opteron box. The machine continued to run a few rounds of kernbench
and LTP. Looks a bit scary -- a tasklet
On Sat, Feb 24, 2007 at 10:37:44PM -0800, David Miller wrote:
From: Ingo Molnar [EMAIL PROTECTED]
Date: Sun, 25 Feb 2007 07:27:47 +0100
* Paul E. McKenney [EMAIL PROTECTED] wrote:
I got the following running stock 2.6.20-rt8 on an 4-CPU 1.8GHz
Opteron box. The machine continued
On Tue, Feb 27, 2007 at 12:25:17PM -0800, Andrew Morton wrote:
On Sun, 25 Feb 2007 23:06:21 +0300 Oleg Nesterov [EMAIL PROTECTED] wrote:
page_lock_anon_vma() uses spin_lock() to block RCU. This doesn't work with
PREEMPT_RCU, we have to do rcu_read_lock() explicitely. Otherwise, it is
On Thu, Mar 01, 2007 at 11:29:03AM -0800, Josh Triplett wrote:
Acked-by: Paul E. McKenney [EMAIL PROTECTED]
Signed-off-by: Josh Triplett [EMAIL PROTECTED]
---
The corresponding rcu_torture_cleanup cannot get marked as __exit, because
rcu_torture_init uses it to clean up if init fails
On Thu, Mar 01, 2007 at 08:54:25PM +0100, Rafael J. Wysocki wrote:
On Thursday, 1 March 2007 20:38, Anton Blanchard wrote:
Hi,
Remove PF_NOFREEZE from the rcutorture thread, adding a
try_to_freeze() call as required.
...
@@ -607,6 +607,7 @@ rcu_torture_writer(void *arg)
On Fri, Mar 02, 2007 at 12:27:30PM +0530, Gautham R Shenoy wrote:
From: Paul E. McKenney [EMAIL PROTECTED]
Remove PF_NOFREEZE from the rcutorture thread, adding a try_to_freeze()
call as
required.
Signed-off-by: Paul E. McKenney [EMAIL PROTECTED]
Signed-off-by: Rafael J. Wysocki
On Sat, Mar 03, 2007 at 02:33:37AM +0300, Oleg Nesterov wrote:
On 03/02, Paul E. McKenney wrote:
One way to embed try_to_freeze() into kthread_should_stop() might be
as follows:
int kthread_should_stop(void)
{
if (kthread_stop_info.k == current
On Mon, Mar 26, 2007 at 10:46:39AM +0200, Lennert Buytenhek wrote:
On Sun, Mar 25, 2007 at 08:24:18PM -0700, Paul E. McKenney wrote:
[ background: On ARM, SMP synchronisation does need barriers but
device
synchronisation does not. The question is that given
On Sat, Jan 12, 2008 at 10:23:11AM +0100, Peter Zijlstra wrote:
On Fri, 2008-01-11 at 20:26 -0500, Benjamin LaHaise wrote:
Hello folks,
I'd like to put the patch below out for comments to see if folks think the
approach is a valid fix to reduce the latency of synchronize_rcu(). The
PROTECTED]
Fine by me.
Acked-by: Josh Triplett [EMAIL PROTECTED]
And me.
Acked-by: Paul E. McKenney [EMAIL PROTECTED]
Thanx, Paul
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
The _safe list iterators make a blanket statement about how they are
safe against removal. This patch, inspired by private conversations
with people who unwisely but perhaps understandably took this blanket
statement at its word, adds comments stating limits to this safety.
Signed-off-by: Paul E
On Thu, Sep 13, 2007 at 04:22:59PM +0400, Evgeniy Polyakov wrote:
Hi Paul.
On Mon, Sep 10, 2007 at 03:14:45PM -0700, Paul E. McKenney ([EMAIL
PROTECTED]) wrote:
Further TODO list includes:
* implement optional saving of mirroring/linear information on the remote
nodes (simple
On Thu, Sep 13, 2007 at 02:22:45AM -0700, Matthew Helsley wrote:
On Wed, 2007-09-12 at 18:01 -0700, Paul E. McKenney wrote:
The _safe list iterators make a blanket statement about how they are
safe against removal. This patch, inspired by private conversations
with people who unwisely
On Fri, Sep 14, 2007 at 11:14:58PM +0200, Johannes Berg wrote:
On Mon, 2007-09-10 at 10:39 -0700, Paul E. McKenney wrote:
On Mon, Sep 10, 2007 at 02:05:47PM +0200, Johannes Berg wrote:
To implement the multicast list callback in mac80211 we need to
do partial list iteration. Since I want
On Tue, Sep 18, 2007 at 02:24:51PM +0200, Peter Zijlstra wrote:
On Tue, 18 Sep 2007 03:34:00 -0700 Andrew Morton
[EMAIL PROTECTED] wrote:
Well, it was an optimisation. spin_lock() implies rcu_read_lock(). That's
a bit dirty and we might choose to not do that.
Not true for the
On Tue, Sep 18, 2007 at 09:57:15AM -0700, Andrew Morton wrote:
On Tue, 18 Sep 2007 09:13:37 -0700 Paul E. McKenney [EMAIL PROTECTED]
wrote:
On Tue, Sep 18, 2007 at 02:24:51PM +0200, Peter Zijlstra wrote:
On Tue, 18 Sep 2007 03:34:00 -0700 Andrew Morton
[EMAIL PROTECTED] wrote
On Tue, Sep 18, 2007 at 10:27:01PM +0200, Peter Zijlstra wrote:
warn when rcu_dereference() is used outside of rcu_read_lock()
Cool!!!
[ generates a _lot_ of output when booted ]
I bet! If you create an annotation for rcu_read_lock_bh()
and rcu_read_unlock_bh() like you did for
On Wed, Sep 19, 2007 at 11:16:21AM -0400, Dmitry Torokhov wrote:
On 9/19/07, Peter Zijlstra [EMAIL PROTECTED] wrote:
On Wed, 19 Sep 2007 10:17:25 -0400 Dmitry Torokhov
[EMAIL PROTECTED] wrote:
Hi Peter,
On 9/19/07, Peter Zijlstra [EMAIL PROTECTED] wrote:
Warn when
On Wed, Sep 19, 2007 at 12:59:10PM -0400, Dmitry Torokhov wrote:
On 9/19/07, Paul E. McKenney [EMAIL PROTECTED] wrote:
On Wed, Sep 19, 2007 at 11:16:21AM -0400, Dmitry Torokhov wrote:
On 9/19/07, Peter Zijlstra [EMAIL PROTECTED] wrote:
On Wed, 19 Sep 2007 10:17:25 -0400 Dmitry Torokhov
On Wed, Sep 19, 2007 at 10:32:49AM -0700, Paul E. McKenney wrote:
On Wed, Sep 19, 2007 at 12:59:10PM -0400, Dmitry Torokhov wrote:
On 9/19/07, Paul E. McKenney [EMAIL PROTECTED] wrote:
On Wed, Sep 19, 2007 at 11:16:21AM -0400, Dmitry Torokhov wrote:
On 9/19/07, Peter Zijlstra [EMAIL
On Wed, Sep 19, 2007 at 03:49:24PM -0400, Dmitry Torokhov wrote:
On 9/19/07, Peter Zijlstra [EMAIL PROTECTED] wrote:
On Wed, 19 Sep 2007 14:49:56 -0400 Dmitry Torokhov
[EMAIL PROTECTED] wrote:
On 9/19/07, Paul E. McKenney [EMAIL PROTECTED] wrote:
PS to previous -- any problem
interesting side-effect of the overall patch is that one must select
CONFIG_PREEMPT in order for a CONFIG_DEBUG_LOCK_ALLOC build to compile.
Might be OK, but thought I should mention it.
Signed-off-by: Paul E. McKenney [EMAIL PROTECTED]
diff -urpNa -X dontdiff linux-2.6.22-rcudep/kernel/srcu.c
On Mon, Nov 12, 2007 at 07:48:45AM +1100, Benjamin Herrenschmidt wrote:
On Sun, 2007-11-11 at 09:45 -0500, Steven Rostedt wrote:
Well, I suppose the patch could go in, maybe with some ifdef's
around
the bits in _switch_to, there's little point in doing that on non-rt
kernels.
As
] [c00e73ec] .sys_ioctl+0x98/0xe0
[c000ff49fc50] [c0117944] .dev_ifsioc+0x1e0/0x46c
[c000ff49fd40] [c011e1d4] .compat_sys_ioctl+0x40c/0x4a0
[c000ff49fe30] [c000852c] syscall_exit+0x0/0x40
Signed-off-by: Paul E. McKenney [EMAIL PROTECTED]
---
arch/powerpc/kernel
On Tue, Dec 04, 2007 at 02:45:06PM -0500, Mathieu Desnoyers wrote:
* Andrew Morton ([EMAIL PROTECTED]) wrote:
On Tue, 4 Dec 2007 14:21:00 -0500
Mathieu Desnoyers [EMAIL PROTECTED] wrote:
+ */
+void marker_probe_cb(const struct marker *mdata, void *call_private,
+ const
On Tue, Dec 04, 2007 at 01:18:46PM -0500, Mathieu Desnoyers wrote:
RCU style multiple probes support for the Linux Kernel Markers.
Common case (one probe) is still fast and does not require dynamic allocation
or a supplementary pointer dereference on the fast path.
- Move preempt disable
On Thu, Dec 20, 2007 at 09:25:40AM -0500, Mathieu Desnoyers wrote:
* Paul E. McKenney ([EMAIL PROTECTED]) wrote:
On Tue, Dec 04, 2007 at 02:45:06PM -0500, Mathieu Desnoyers wrote:
* Andrew Morton ([EMAIL PROTECTED]) wrote:
On Tue, 4 Dec 2007 14:21:00 -0500
Mathieu Desnoyers [EMAIL
On Fri, Nov 30, 2007 at 12:11:28AM +0530, K. Prasad wrote:
Hi,
Please review the ensuing set of patches which convert the
existing RCU tracing mechanism for Preempt RCU and RCU Boost into
markers.
These patches are based upon the 2.6.24-rc2-rt1 kernel tree.
Along with marker
-NULL
and const/non-const) with gcc version 4.1.2, and hand-checked the
assembly output.
Signed-off-by: Paul E. McKenney [EMAIL PROTECTED]
---
rcupdate.h | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff -urpNa -X dontdiff linux-2.6.24-rc1-ego/include/linux/rcupdate.h
linux
On Sat, Dec 01, 2007 at 12:07:52PM +1100, Herbert Xu wrote:
On Fri, Nov 30, 2007 at 04:37:21PM -0800, Paul E. McKenney wrote:
The rcu_assign_pointer() primitive currently unconditionally executes
a memory barrier, even when a NULL pointer is being assigned. This
has lead some to avoid
On Tue, Nov 20, 2007 at 07:43:09PM -0800, James Huang wrote:
Please disregard the previous email.
In the latest Linux 2.6 RCU implementation, __rcu_process_callbacks() is
coded as follows:
422 static void __rcu_process_callbacks(struct rcu_ctrlblk *rcp,
423
that I have missed, this one is messy
enough that an additional explicit memory barrier might be in order.
Manfred? Dipankar?
Thanks,
James Huang
- Original Message
From: Paul E. McKenney [EMAIL PROTECTED]
To: James Huang [EMAIL PROTECTED]
Cc: linux-kernel@vger.kernel.org
: Manfred Spraul [EMAIL PROTECTED]
To: James Huang [EMAIL PROTECTED]
Cc: Paul E. McKenney [EMAIL PROTECTED]; linux-
[EMAIL PROTECTED]
Sent: Monday, November 26, 2007 10:28:37 AM
Subject: __rcu_process_callbacks() in Linux 2.6
Hi James,
If I understand the issue correctly, then the race
On Mon, Nov 26, 2007 at 06:39:58PM -0800, Paul E. McKenney wrote:
On Mon, Nov 26, 2007 at 02:48:08PM -0800, James Huang wrote:
-Original Message-
From: James Huang [mailto:[EMAIL PROTECTED]
Sent: Monday, November 26, 2007 2:21 PM
To: James Huang
Subject: Fw
On Tue, Nov 27, 2007 at 05:49:15PM -0800, Paul E. McKenney wrote:
On Mon, Nov 26, 2007 at 06:39:58PM -0800, Paul E. McKenney wrote:
On Mon, Nov 26, 2007 at 02:48:08PM -0800, James Huang wrote:
From: James Huang [mailto:[EMAIL PROTECTED]
Sent: Monday, November 26, 2007 2:21 PM
On Tue, Nov 27, 2007 at 10:21:08PM -0800, Paul E. McKenney wrote:
On Tue, Nov 27, 2007 at 05:49:15PM -0800, Paul E. McKenney wrote:
On Mon, Nov 26, 2007 at 06:39:58PM -0800, Paul E. McKenney wrote:
On Mon, Nov 26, 2007 at 02:48:08PM -0800, James Huang wrote:
[ . . . ]
That is correct
On Wed, Dec 12, 2007 at 10:56:12PM -0500, Steven Rostedt wrote:
On Mon, 29 Oct 2007, Paul E. McKenney wrote:
diff -urpNa -X dontdiff linux-2.6.23.1-rt4/mm/memory.c
linux-2.6.23.1-rt4-fix/mm/memory.c
--- linux-2.6.23.1-rt4/mm/memory.c 2007-10-27 22:20:57.0 -0700
+++ linux
On Thu, Dec 13, 2007 at 07:52:41AM -0500, Steven Rostedt wrote:
On Wed, 12 Dec 2007, Paul E. McKenney wrote:
I'm pulling your patch for the above added code. Took me a few hours to
find the culprit, but I was getting scheduling in atomic bugs. Turns out
that this code you put
On Thu, Dec 13, 2007 at 09:38:04PM +0100, Ingo Molnar wrote:
* Gautham R Shenoy [EMAIL PROTECTED] wrote:
Hello everyone,
This patchset is an updated version of the preemptible RCU patchset
that Paul McKenney had posted it in September earlier this year that
can be found here --
On Fri, Dec 14, 2007 at 03:51:14PM +0100, Johannes Weiner wrote:
Hi,
Gautham R Shenoy [EMAIL PROTECTED] writes:
diff --git a/kernel/rcuclassic.c b/kernel/rcuclassic.c
new file mode 100644
index 000..11c16aa
--- /dev/null
+++ b/kernel/rcuclassic.c
+/**
+ * call_rcu - Queue
re-enabled,
but there is likely a better approach.
Thoughts?
Signed-off-by: Paul E. McKenney [EMAIL PROTECTED]
---
arch/powerpc/kernel/prom.c |2 +-
arch/powerpc/mm/fault.c |3 +++
arch/powerpc/mm/tlb_64.c |8 ++--
arch/powerpc
On Tue, Oct 30, 2007 at 07:07:48AM +1100, Benjamin Herrenschmidt wrote:
On Mon, 2007-10-29 at 11:50 -0700, Paul E. McKenney wrote:
Hello!
A few random patches that permit POWER to pass kernbench on -rt.
Many of these have more focus on expediency than care for correctness,
so might
On Tue, Oct 30, 2007 at 07:37:50AM +1100, Benjamin Herrenschmidt wrote:
On Mon, 2007-10-29 at 13:26 -0700, Paul E. McKenney wrote:
I see a lot of case where you add preempt_disable/enable around
areas
that have the PTE lock held...
So in -rt, spin_lock doesn't disable preempt
here?
Signed-off-by: Paul E. McKenney [EMAIL PROTECTED]
---
nf_nat_h323.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff -urpNa -X dontdiff linux-2.6.23/net/ipv4/netfilter/nf_nat_h323.c
linux-2.6.23-rcufix/net/ipv4/netfilter/nf_nat_h323.c
--- linux-2.6.23/net
Hello!
net/decnet/dn_route.c in dn_rt_cache_get_next() is as follows:
static struct dn_route *dn_rt_cache_get_next(struct seq_file *seq, struct
dn_route *rt)
{
struct dn_rt_cache_iter_state *s = rcu_dereference(seq-private);
rt = rt-u.dst.dn_next;
while(!rt) {
On Tue, Oct 30, 2007 at 01:10:36AM -0700, David Miller wrote:
From: Paul E. McKenney [EMAIL PROTECTED]
Date: Mon, 29 Oct 2007 14:15:40 -0700
net/decnet/dn_route.c in dn_rt_cache_get_next() is as follows:
static struct dn_route *dn_rt_cache_get_next(struct seq_file *seq, struct
On Tue, Oct 30, 2007 at 03:06:20PM +0100, Patrick McHardy wrote:
Paul E. McKenney wrote:
Hello!
While reviewing rcu_dereference() uses, I came across a number of cases
where I couldn't see how the rcu_dereference() helped. One class of
cases is where the variable is never subsequently
On Sat, Feb 09, 2008 at 12:34:35PM +0100, Heiko Carstens wrote:
Using CONFIG_PREEMPT_RCU and CONFIG_NO_IDLE_HZ on s390 my system always
gets stuck when running with more than one cpu.
When booting with four cpus I get all four cpus caught withing cpu_idle
and not advancing anymore. However
On Sat, Feb 09, 2008 at 06:14:51PM +0100, Heiko Carstens wrote:
On Sat, Feb 09, 2008 at 06:07:11AM -0800, Paul E. McKenney wrote:
On Sat, Feb 09, 2008 at 12:34:35PM +0100, Heiko Carstens wrote:
Using CONFIG_PREEMPT_RCU and CONFIG_NO_IDLE_HZ on s390 my system always
gets stuck when running
On Sun, Feb 10, 2008 at 02:01:50PM +0100, Heiko Carstens wrote:
Using CONFIG_PREEMPT_RCU and CONFIG_NO_IDLE_HZ on s390 my system
always
gets stuck when running with more than one cpu.
When booting with four cpus I get all four cpus caught withing
cpu_idle
and not
.
Thanx, Paul
Signed-off-by: Paul E. McKenney [EMAIL PROTECTED]
---
rcupdate.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff -urpNa -X dontdiff linux-2.6.24/kernel/rcupdate.c
linux-2.6.24-wakeme-comment/kernel/rcupdate.c
--- linux-2.6.24/kernel
want a memory
barrier in this case.
So how about leaving the index-unfriendly version of rcu_assign_pointer()
and adding an rcu_assign_index() as follows?
Thanx, Paul
Signed-off-by: Paul E. McKenney [EMAIL PROTECTED]
---
rcupdate.h | 18
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]
---
rcupdate.h | 16
-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:47.0
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 cursor.
+ *
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
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:
http://archives.free.net.ph/message/20071201.003721
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 2008 14:00:24 -0800
Paul E. McKenney [EMAIL PROTECTED] wrote
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 -0800
Paul E. McKenney [EMAIL PROTECTED] wrote
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 cast both sides to void * in this case:
static inline
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 towards ugly... Maybe not using the macro at all
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 structure allocated out of an array
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 structure allocated out of an array, using
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 paul...@linux.vnet.ibm.com
This commit fixes a broken example of overlapping stores in the
Documentation/memory-barriers.txt file.
Reported-by: Nikunj A Dadhania nik...@linux.vnet.ibm.com
Signed-off-by: Paul E. McKenney paul...@linux.vnet.ibm.com
---
Documentation/memory
From: Paul E. McKenney paul...@linux.vnet.ibm.com
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
From: Kees Cook keesc...@chromium.org
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 keesc...@chromium.org
Signed-off-by: Paul E. McKenney paul...@linux.vnet.ibm.com
-by: Paul E. McKenney paul...@linux.vnet.ibm.com
---
Documentation/RCU/RTFP.txt |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/RCU/RTFP.txt b/Documentation/RCU/RTFP.txt
index 7c1dfb1..7f40c72 100644
--- a/Documentation/RCU/RTFP.txt
+++ b/Documentation/RCU/RTFP.txt
introduces DEFINE_SRCU()
and DEFINE_STATIC_SRCU() to allow statically declared SRCU structures,
using the new static per-CPU interfaces.
Signed-off-by: Lai Jiangshan la...@cn.fujitsu.com
Signed-off-by: Paul E. McKenney paul...@linux.vnet.ibm.com
[ paulmck: Updated for __DELAYED_WORK_INITIALIZER
From: Lai Jiangshan la...@cn.fujitsu.com
Use DEFINE_STATIC_SRCU() to simplify the rcutorture.c SRCU test code.
Signed-off-by: Lai Jiangshan la...@cn.fujitsu.com
Reviewed-by: Josh Triplett j...@joshtriplett.org
Signed-off-by: Paul E. McKenney paul...@linux.vnet.ibm.com
---
kernel/rcutorture.c
From: Lai Jiangshan la...@cn.fujitsu.com
Lai Jiangshan rewrote SRCU, so this commit ensures that he gets his
proper share of blame^Wcredit.
Signed-off-by: Lai Jiangshan la...@cn.fujitsu.com
Signed-off-by: Paul E. McKenney paul...@linux.vnet.ibm.com
---
include/linux/srcu.h |2 ++
kernel
From: Paul E. McKenney paul...@linux.vnet.ibm.com
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
From: Paul E. McKenney paul.mcken...@linaro.org
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
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
From: Paul E. McKenney paul...@linux.vnet.ibm.com
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 paul...@linux.vnet.ibm.com
---
Documentation/RCU
From: Paul E. McKenney paul...@linux.vnet.ibm.com
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
-off-by: Paul E. McKenney paul...@linux.vnet.ibm.com
---
include/linux/srcu.h |2 ++
kernel/srcu.c|6 ++
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/srcu.h b/include/linux/srcu.h
index a55ddb1..5cce128 100644
--- a/include/linux/srcu.h
+++ b
From: Paul E. McKenney paul...@linux.vnet.ibm.com
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
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
1 - 100 of 21761 matches
Mail list logo
