-off-by: Mathieu Desnoyers mathieu.desnoy...@efficios.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
Signed-off-by: Paul E. McKenney paul...@linux.vnet.ibm.com
diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
index ebc2f38..2c7e801
On Wed, May 14, 2008 at 09:04:07PM +0530, Kamalesh Babulal wrote:
Hi Andrew,
2.6.26-rc2-mm1 kernel panics on powerpc, while running ltp test over it.
I have attached the gdb output of the pc and lr registers. The patch
list_for_each_rcu-must-die-networking.patch points to changes made
to
On Thu, May 15, 2008 at 12:05:46AM +0400, Alexey Dobriyan wrote:
On Wed, May 14, 2008 at 09:07:05AM -0700, Paul E. McKenney wrote:
On Wed, May 14, 2008 at 09:04:07PM +0530, Kamalesh Babulal wrote:
Hi Andrew,
2.6.26-rc2-mm1 kernel panics on powerpc, while running ltp test over it.
I
,
and also to fix my bonehead error detected by Kamalesh Babulal and
Alexey Dobriyan. It now passes LTP on POWER. And also has valid SOB.
Some days it just doesn't pay to get out of bed...
Acked-by: David S. Miller [EMAIL PROTECTED] (lkml.org/lkml/2008/4/23/448)
Signed-off-by: Paul E. McKenney [EMAIL
On Thu, May 22, 2008 at 02:18:17PM -0400, Steven Rostedt wrote:
In rcupreempt, rcu_batches_completed_bh is defined as a static inline in
the header file. This does not need to be exported, and not only that,
this breaks my PPC build.
Good catch!!!
Reviewed-by: Paul E. McKenney [EMAIL
Make powerpc refrain from clearing a given to-be-offlined CPU's bit in the
cpu_online_mask until it has processed pending irqs. This change
prevents other CPUs from being blindsided by an apparently offline CPU
nevertheless changing globally visible state.
Signed-off-by: Paul E. McKenney [EMAIL
On Mon, Sep 01, 2008 at 10:34:44AM +1000, Benjamin Herrenschmidt wrote:
On Sun, 2008-08-31 at 10:31 -0700, Paul E. McKenney wrote:
Make powerpc refrain from clearing a given to-be-offlined CPU's bit in the
cpu_online_mask until it has processed pending irqs. This change
prevents other CPUs
On Mon, Sep 01, 2008 at 01:14:40PM +1000, Benjamin Herrenschmidt wrote:
On Sun, 2008-08-31 at 19:06 -0700, Paul E. McKenney wrote:
On Mon, Sep 01, 2008 at 10:34:44AM +1000, Benjamin Herrenschmidt wrote:
On Sun, 2008-08-31 at 10:31 -0700, Paul E. McKenney wrote:
Make powerpc refrain from
Hello!
I get the following during boot on a 16 CPU Power box. Thoughts?
(/proc/config attached)
Thanx, Paul
UDP hash table entries: 2048 (order: 6, 262144 bytes)
UDP-Lite hash table entries: 2048 (order: 6, 262144 bytes)
NET: Registered
On Thu, Jun 10, 2010 at 09:20:08AM +1000, Benjamin Herrenschmidt wrote:
On Wed, 2010-06-09 at 14:52 -0700, Paul E. McKenney wrote:
Hello!
I get the following during boot on a 16 CPU Power box. Thoughts?
(/proc/config attached)
Wow... looks like the preempt count of the idle task got
crash_kexec_wait_realmode() is defined only if CONFIG_PPC_STD_MMU_64
and CONFIG_SMP, but is called if CONFIG_PPC_STD_MMU_64 even if !CONFIG_SMP.
Fix the conditional compilation around the invocation.
Untested, probably does not compile.
Signed-off-by: Paul E. McKenney paul...@linux.vnet.ibm.com
the conditional compilation around the invocation.
Untested, probably does not compile.
Signed-off-by: Paul E. McKenney paul...@linux.vnet.ibm.com
This should be right since we don't need to wait for the other CPUs if
there are no others...
Compiles for me and even fixes the SMP=N case
this property it obliges and terminates our partition.
Use DIV_ROUND_UP so we handle not only the CONFIG_SMP=n case but also the
case where NR_CPUS isn't a multiple of the number of SMT threads.
Thank you, Anton!!!
Acked-by: Paul E. McKenney paul...@linux.vnet.ibm.com
(Will test as soon as the system
On Wed, Jun 09, 2010 at 06:08:54PM -0700, Paul E. McKenney wrote:
On Thu, Jun 10, 2010 at 09:20:08AM +1000, Benjamin Herrenschmidt wrote:
On Wed, 2010-06-09 at 14:52 -0700, Paul E. McKenney wrote:
Hello!
I get the following during boot on a 16 CPU Power box. Thoughts?
(/proc
, Aug 05, 2010 at 01:31:10PM -0400, Ilia Mirkin wrote:
On Thu, Jul 1, 2010 at 6:18 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
On Thu, Jul 01, 2010 at 08:21:43AM -0400, Miles Lane wrote:
[ INFO: suspicious rcu_dereference_check() usage
On Thu, Sep 16, 2010 at 05:50:31PM +0200, Peter Zijlstra wrote:
On Mon, 2010-08-09 at 09:12 -0700, Paul E. McKenney wrote:
[0.051203] CPU0: AMD QEMU Virtual CPU version 0.12.4 stepping 03
[0.052999] lockdep: fixing up alternatives.
[0.054105]
[0.054106
been
synchronize_sched().
Acked-by: Paul E. McKenney [EMAIL PROTECTED]
Signed-off-by: Stephen Rothwell [EMAIL PROTECTED]
---
arch/powerpc/platforms/iseries/lpevents.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/iseries/lpevents.c
b
functions to prevent false-
positive warnings from the CPU hotplug debug code. Also, add a comment
explaining the hotplug synchronization design used in RCU, so that its easy
to see why it is justified to use the _nocheck() variants.
Cc: Dipankar Sarma dipan...@in.ibm.com
Cc: Paul E. McKenney paul
On Sat, Mar 31, 2012 at 06:40:30PM +0200, Geert Uytterhoeven wrote:
Hi Paul,
On Sat, Mar 31, 2012 at 18:33, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
Although there have been numerous complaints about the complexity of
parallel programming (especially over the past 5-10 years
On Sat, Mar 31, 2012 at 01:25:02PM -0700, Randy Dunlap wrote:
On 03/31/2012 01:15 PM, Linas Vepstas wrote:
Hi,
I didn't actually try to compile the patch below; it didn't look like
C code so I wasn't sure what compiler to run it through. I guess maybe
its python? However, I'm
On Sat, Mar 31, 2012 at 11:00:08PM +0200, Eric Dumazet wrote:
On Sun, 2012-04-01 at 00:33 +0800, Paul E. McKenney wrote:
Although there have been numerous complaints about the complexity of
parallel programming (especially over the past 5-10 years), the plain
truth is that the incremental
will end up with a very large patch set. ;-)
Thanx, Paul
Regards,
Lorenz Kolb
Am 31.03.2012 23:21, schrieb Paul E. McKenney:
On Sat, Mar 31, 2012 at 11:00:08PM +0200, Eric Dumazet wrote:
On Sun, 2012-04-01 at 00:33 +0800, Paul E
On Sat, Mar 31, 2012 at 11:32:00PM +0100, Russell King - ARM Linux wrote:
On Sun, Apr 01, 2012 at 12:33:21AM +0800, Paul E. McKenney wrote:
Although there have been numerous complaints about the complexity of
parallel programming (especially over the past 5-10 years), the plain
truth
On Sun, Apr 01, 2012 at 12:04:48PM +0200, Borislav Petkov wrote:
On Sun, Apr 01, 2012 at 12:33:21AM +0800, Paul E. McKenney wrote:
Although there have been numerous complaints about the complexity of
parallel programming (especially over the past 5-10 years), the plain
truth
On Sun, Apr 01, 2012 at 07:34:55PM +0200, Thomas Gleixner wrote:
On Sat, 31 Mar 2012, Russell King - ARM Linux wrote:
On Sun, Apr 01, 2012 at 12:33:21AM +0800, Paul E. McKenney wrote:
Although there have been numerous complaints about the complexity of
parallel programming (especially
On Mon, Apr 30, 2012 at 03:37:10PM -0700, Hugh Dickins wrote:
Hi Paul,
On 3.4.0-rc4-next-20120427 and preceding linux-nexts (I've not tried
rc5-next-20120430 but expect it's the same), on PowerPC G5 quad with
CONFIG_PREEMPT=y and CONFIG_DEBUG_ATOMIC_SLEEP=y, I'm getting spurious
BUG:
On Tue, May 01, 2012 at 10:33:38AM +1000, Benjamin Herrenschmidt wrote:
On Mon, 2012-04-30 at 15:37 -0700, Hugh Dickins wrote:
BUG: sleeping function called from invalid context at
include/linux/pagemap.h:354
in_atomic(): 0, irqs_disabled(): 0, pid: 6886, name: cc1
Hrm ... in_atomic
e798cf3385d3aa7c84afa65677eb92e0c0876dfd
# good: [90aec3b06194393c909e3e5a47b6ed99bb8caba5] rcu: Make exit_rcu() more
precise and consolidate
git bisect good 90aec3b06194393c909e3e5a47b6ed99bb8caba5
from which I concluded that the patch responsible is
commit ab8fc41a8545d40a4b58d745876c125af72a8a5c
Author: Paul E
On Tue, May 01, 2012 at 02:42:02PM -0700, Hugh Dickins wrote:
On Tue, 1 May 2012, Paul E. McKenney wrote:
On Mon, Apr 30, 2012 at 10:10:06PM -0700, Hugh Dickins wrote:
On Tue, 1 May 2012, Benjamin Herrenschmidt wrote:
On Mon, 2012-04-30 at 15:37 -0700, Hugh Dickins wrote:
BUG
On Wed, May 02, 2012 at 01:25:30PM -0700, Hugh Dickins wrote:
On Tue, 1 May 2012, Paul E. McKenney wrote:
On Mon, 2012-04-30 at 15:37 -0700, Hugh Dickins wrote:
BUG: sleeping function called from invalid context at
include/linux/pagemap.h:354
in_atomic(): 0
On Wed, May 02, 2012 at 01:49:54PM -0700, Paul E. McKenney wrote:
On Wed, May 02, 2012 at 01:25:30PM -0700, Hugh Dickins wrote:
On Tue, 1 May 2012, Paul E. McKenney wrote:
On Mon, 2012-04-30 at 15:37 -0700, Hugh Dickins wrote:
BUG: sleeping function called from invalid
On Wed, May 02, 2012 at 02:32:38PM -0700, Paul E. McKenney wrote:
On Wed, May 02, 2012 at 01:49:54PM -0700, Paul E. McKenney wrote:
On Wed, May 02, 2012 at 01:25:30PM -0700, Hugh Dickins wrote:
On Tue, 1 May 2012, Paul E. McKenney wrote:
On Mon, 2012-04-30 at 15:37 -0700, Hugh
On Thu, May 03, 2012 at 07:20:15AM +1000, Benjamin Herrenschmidt wrote:
On Wed, 2012-05-02 at 13:25 -0700, Hugh Dickins wrote:
Got it at last. Embarrassingly obvious. __rcu_read_lock() and
__rcu_read_unlock() are not safe to be using __this_cpu operations,
the cpu may change in between
On Wed, May 02, 2012 at 03:54:24PM -0700, Hugh Dickins wrote:
On Wed, May 2, 2012 at 2:54 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
On Thu, May 03, 2012 at 07:20:15AM +1000, Benjamin Herrenschmidt wrote:
On Wed, 2012-05-02 at 13:25 -0700, Hugh Dickins wrote:
Got it at last
On Mon, May 07, 2012 at 09:21:54AM -0700, Hugh Dickins wrote:
On Wed, 2 May 2012, Hugh Dickins wrote:
On Wed, 2 May 2012, Paul E. McKenney wrote:
In any case, I must confess that I feel quite silly about my series
of patches. I have reverted them aside from a couple that did useful
On Tue, May 29, 2012 at 03:16:04PM +0800, Yong Zhang wrote:
From: Yong Zhang yong.zh...@windriver.com
1) call_function.lock used in smp_call_function_many() is just to protect
call_function.queue and data-refs, cpu_online_mask is outside of the
lock. And it's not necessary to protect
On Sat, Jun 16, 2012 at 07:30:58PM +0200, Peter Zijlstra wrote:
On Sat, 2012-06-16 at 09:32 -0700, Paul E. McKenney wrote:
However, there is an effort to get rid of stop_machine() from the
CPU-down path... So something else will be needed.
Elsewhere in this thread I mentioned we could do
On Mon, Jun 18, 2012 at 10:35:46AM +1000, Benjamin Herrenschmidt wrote:
Hi Paul !
I was about to go debug something else when I hit that with -rc3 (plus
the patch to fix the current bug.h breakage) on a 32-bit PowerMac G4 SMP
(2 CPUs): About 1mn pause at boot followed by a bunch of RCU stall
On Mon, Jun 18, 2012 at 10:51:59AM +0800, Yong Zhang wrote:
On Sat, Jun 16, 2012 at 09:32:19AM -0700, Paul E. McKenney wrote:
On Tue, May 29, 2012 at 03:16:04PM +0800, Yong Zhang wrote:
From: Yong Zhang yong.zh...@windriver.com
1) call_function.lock used in smp_call_function_many
On Tue, Jun 19, 2012 at 06:45:31AM +1000, Benjamin Herrenschmidt wrote:
Hi Paul !
On Mon, 2012-06-18 at 10:05 -0700, Paul E. McKenney wrote:
sd 0:0:0:0: Attached scsi generic sg0 type 0
sda: [mac] sda1 sda2 sda3 sda4 sda5 sda6 sda7 sda8 sda9 sda10 sda11
sda12 sda13 sda14 sda15
On Mon, Jun 18, 2012 at 02:58:57PM -0700, Paul E. McKenney wrote:
On Tue, Jun 19, 2012 at 06:45:31AM +1000, Benjamin Herrenschmidt wrote:
Hi Paul !
On Mon, 2012-06-18 at 10:05 -0700, Paul E. McKenney wrote:
sd 0:0:0:0: Attached scsi generic sg0 type 0
sda: [mac] sda1 sda2 sda3
On Sun, Jul 01, 2012 at 11:30:40PM -0700, Christian Kujau wrote:
On Mon, 2 Jul 2012 at 14:50, Benjamin Herrenschmidt wrote:
Interesting... I observed something roughly similar on a dual G4
the other day associated with a 30s to 1mn pause during boot. RCU
was complaining loudly.
In my
-by: Paul E. McKenney paul...@linux.vnet.ibm.com
Reviewed-by: Lai Jiangshan la...@cn.fujitsu.com
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 3f93033d3c61..8f3e4d43d736 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1013,10 +1013,7 @@ static void record_gp_stall_check_time
.
Thanx, Paul
documentation: Record limitations of bitfields and small variables
This commit documents the fact that it is not safe to use bitfields
as shared variables in synchronization algorithms.
Signed-off-by: Paul E
On Thu, Sep 04, 2014 at 10:47:24PM -0400, Peter Hurley wrote:
Hi James,
On 09/04/2014 10:11 PM, James Bottomley wrote:
On Thu, 2014-09-04 at 17:17 -0700, Paul E. McKenney wrote:
+And there are anti-guarantees:
+
+ (*) These guarantees do not apply to bitfields, because compilers often
-by: Paul E. McKenney paul...@linux.vnet.ibm.com
diff --git a/Documentation/memory-barriers.txt
b/Documentation/memory-barriers.txt
index 87be0a8a78de..455df6b298f7 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -269,6 +269,30 @@ And there are a number
On Fri, Sep 05, 2014 at 11:09:50AM -0700, Paul E. McKenney wrote:
On Fri, Sep 05, 2014 at 08:16:48PM +1200, Michael Cree wrote:
On Thu, Sep 04, 2014 at 07:08:48PM -0700, H. Peter Anvin wrote:
On 09/04/2014 05:59 PM, Peter Hurley wrote:
I have no idea how prevalent the ev56 is compared
On Fri, Sep 05, 2014 at 02:50:31PM -0400, Peter Hurley wrote:
On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
On Fri, Sep 05, 2014 at 08:16:48PM +1200, Michael Cree wrote:
On Thu, Sep 04, 2014 at 07:08:48PM -0700, H. Peter Anvin wrote:
On 09/04/2014 05:59 PM, Peter Hurley wrote:
I have
On Fri, Sep 05, 2014 at 03:24:35PM -0400, Peter Hurley wrote:
On 09/05/2014 03:05 PM, Paul E. McKenney wrote:
On Fri, Sep 05, 2014 at 02:50:31PM -0400, Peter Hurley wrote:
On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
[cut
On Fri, Sep 05, 2014 at 04:01:35PM -0400, Peter Hurley wrote:
On 09/05/2014 03:52 PM, Peter Zijlstra wrote:
On Fri, Sep 05, 2014 at 11:31:09AM -0700, Paul E. McKenney wrote:
compiler: Allow 1- and 2-byte smp_load_acquire() and smp_store_release()
CPUs without single-byte and double-byte
On Fri, Sep 05, 2014 at 04:14:48PM -0400, Peter Hurley wrote:
On 09/05/2014 03:38 PM, Marc Gauthier wrote:
Paul E. McKenney wrote:
On Fri, Sep 05, 2014 at 02:50:31PM -0400, Peter Hurley wrote:
On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
This commit documents the fact
On Fri, Sep 05, 2014 at 01:34:52PM -0700, H. Peter Anvin wrote:
On 09/05/2014 01:14 PM, Peter Hurley wrote:
Here's how I read the two statements.
First, the commit message:
It [this commit] documents that CPUs [supported by the Linux kernel]
_must provide_ atomic one-byte and
On Fri, Sep 05, 2014 at 10:48:34PM +0200, Thomas Gleixner wrote:
On Fri, 5 Sep 2014, Paul E. McKenney wrote:
On Fri, Sep 05, 2014 at 01:34:52PM -0700, H. Peter Anvin wrote:
On 09/05/2014 01:14 PM, Peter Hurley wrote:
Here's how I read the two statements.
First, the commit
On Sat, Sep 06, 2014 at 10:07:22PM -0700, James Bottomley wrote:
On Thu, 2014-09-04 at 21:06 -0700, Paul E. McKenney wrote:
On Thu, Sep 04, 2014 at 10:47:24PM -0400, Peter Hurley wrote:
Hi James,
On 09/04/2014 10:11 PM, James Bottomley wrote:
On Thu, 2014-09-04 at 17:17 -0700
On Sun, Sep 07, 2014 at 12:04:47PM -0700, James Bottomley wrote:
On Sun, 2014-09-07 at 09:21 -0700, Paul E. McKenney wrote:
On Sat, Sep 06, 2014 at 10:07:22PM -0700, James Bottomley wrote:
On Thu, 2014-09-04 at 21:06 -0700, Paul E. McKenney wrote:
On Thu, Sep 04, 2014 at 10:47:24PM -0400
for partially overlapping stores. ;-)
Thanx, Paul
On September 7, 2014 4:00:19 PM PDT, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
On Sun, Sep 07, 2014 at 12:04:47PM -0700, James Bottomley wrote:
On Sun, 2014-09-07 at 09:21 -0700
On Mon, Sep 08, 2014 at 06:47:35PM -0400, Peter Hurley wrote:
On 09/08/2014 01:59 PM, H. Peter Anvin wrote:
On 09/08/2014 10:52 AM, One Thousand Gnomes wrote:
On Fri, 05 Sep 2014 08:41:52 -0700
H. Peter Anvin h...@zytor.com wrote:
On 09/05/2014 08:31 AM, Peter Hurley wrote:
Which is
On Thu, Sep 11, 2014 at 11:04:11AM +0100, One Thousand Gnomes wrote:
Is *that* what we are talking about? I was added to this conversation
in the middle where it had already generalized, so I had no idea.
No, this is just what brought this craziness to my attention.
None of it is
On Mon, Sep 15, 2014 at 12:24:27AM +0100, One Thousand Gnomes wrote:
So a problem that no one has ever complained about on _any_ arch is suddenly
a problem on a subset of Alpha cpus, but a problem I know exists on Alpha
isn't important because no one's filed a bug about it?
Yes - because
On Thu, Nov 13, 2014 at 01:42:12PM +1100, Michael Ellerman wrote:
On Mon, 2014-11-10 at 14:58 -0600, Paul Clarke wrote:
On 11/10/2014 04:08 AM, Benjamin Herrenschmidt wrote:
On Tue, 2014-10-07 at 14:13 -0500, Paul Clarke wrote:
This patch short-circuits the reset of the decrementer,
On Tue, Nov 18, 2014 at 12:46:56PM +1100, Michael Ellerman wrote:
On Mon, 2014-11-17 at 11:18 -0800, Paul E. McKenney wrote:
On Thu, Nov 13, 2014 at 01:42:12PM +1100, Michael Ellerman wrote:
On Mon, 2014-11-10 at 14:58 -0600, Paul Clarke wrote:
On 11/10/2014 04:08 AM, Benjamin
On Mon, Mar 18, 2013 at 08:26:48AM +1100, Paul Mackerras wrote:
On Sat, Mar 16, 2013 at 12:50:49AM +0800, Lai Jiangshan wrote:
At the point of up_out label in kvmppc_hv_setup_htab_rma(),
srcu read lock is still held.
We have to release it before return.
Signed-off-by: Lai Jiangshan
On Fri, Jun 14, 2013 at 10:31:12PM -0400, Steven Rostedt wrote:
On Sat, 2013-06-15 at 12:21 +1000, Benjamin Herrenschmidt wrote:
On Fri, 2013-06-14 at 22:17 -0400, Steven Rostedt wrote:
On Sat, 2013-06-15 at 12:02 +1000, Benjamin Herrenschmidt wrote:
On Fri, 2013-06-14 at 17:06 -0400,
On Mon, Jun 17, 2013 at 05:42:13PM +1000, Michael Ellerman wrote:
On Sat, Jun 15, 2013 at 12:02:21PM +1000, Benjamin Herrenschmidt wrote:
On Fri, 2013-06-14 at 17:06 -0400, Steven Rostedt wrote:
I was pretty much able to reproduce this on my PA Semi PPC box. Funny
thing is, when I type on
On Tue, Jun 25, 2013 at 05:44:23PM +1000, Michael Ellerman wrote:
On Tue, Jun 25, 2013 at 05:19:14PM +1000, Michael Ellerman wrote:
Here's another trace from 3.10-rc7 plus a few local patches.
And here's another with CONFIG_RCU_CPU_STALL_INFO=y in case that's useful:
PASS running
?
Thanx, Paul
Cc: Dipankar Sarma dipan...@in.ibm.com
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
---
kernel/rcutree.c |4
1 file changed, 4 insertions(+)
diff --git a/kernel/rcutree.c b/kernel/rcutree.c
index
On Wed, Jun 26, 2013 at 06:10:58PM +1000, Michael Ellerman wrote:
On Tue, Jun 25, 2013 at 09:03:32AM -0700, Paul E. McKenney wrote:
On Tue, Jun 25, 2013 at 05:44:23PM +1000, Michael Ellerman wrote:
On Tue, Jun 25, 2013 at 05:19:14PM +1000, Michael Ellerman wrote:
Here's another
On Wed, Jun 26, 2013 at 03:29:40PM +0100, David Laight wrote:
Once stop_machine() is gone from the CPU offline path, we won't be able
to depend on disabling preemption to prevent CPUs from going offline
from under us.
Could you use an rcu-like sequence so that disabling pre-emption
would
On Wed, Jun 26, 2013 at 07:39:40PM +0530, Srivatsa S. Bhat wrote:
On 06/26/2013 03:30 AM, Paul E. McKenney wrote:
On Wed, Jun 26, 2013 at 01:57:55AM +0530, Srivatsa S. Bhat wrote:
Once stop_machine() is gone from the CPU offline path, we won't be able
to depend on disabling preemption
On Wed, Jun 26, 2013 at 03:29:40PM +0100, David Laight wrote:
Once stop_machine() is gone from the CPU offline path, we won't be able
to depend on disabling preemption to prevent CPUs from going offline
from under us.
Could you use an rcu-like sequence so that disabling pre-emption
would
of the protecting lock
to the library.
Reviewed-by: Paul E. McKenney paul...@linux.vnet.ibm.com
Signed-off-by: Milton Miller milt...@bga.com
Index: work.git/arch/powerpc/kernel/irq.c
===
--- work.git.orig/arch/powerpc/kernel/irq.c 2011-05-24
On Fri, Sep 09, 2011 at 10:23:33AM -0700, Olof Johansson wrote:
[+linuxppc-dev]
On Tue, Sep 6, 2011 at 11:00 AM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
The trailing isync/lwsync in PowerPC value-returning atomics needs
to be a sync in order to provide the required ordering
On Fri, May 09, 2014 at 05:47:12PM +1000, Anton Blanchard wrote:
I am seeing an issue where a CPU running perf eventually hangs.
Traces show timer interrupts happening every 4 seconds even
when a userspace task is running on the CPU.
Is this by chance every 4.2 seconds? The reason I ask is
On Fri, May 09, 2014 at 11:50:05PM +0200, Gabriel Paubert wrote:
On Fri, May 09, 2014 at 06:41:13AM -0700, Paul E. McKenney wrote:
On Fri, May 09, 2014 at 05:47:12PM +1000, Anton Blanchard wrote:
I am seeing an issue where a CPU running perf eventually hangs.
Traces show timer interrupts
On Sat, May 10, 2014 at 04:33:37PM +1000, Paul Mackerras wrote:
On Fri, May 09, 2014 at 03:08:45PM -0700, Paul E. McKenney wrote:
On Fri, May 09, 2014 at 11:50:05PM +0200, Gabriel Paubert wrote:
On Fri, May 09, 2014 at 06:41:13AM -0700, Paul E. McKenney wrote:
On Fri, May 09, 2014 at 05
an...@samba.org
That is what I call invoking tracepoints the hard way -- from assembly!
Just one question -- can these tracepoints be invoked from the idle
loop? If so, you need to use the _rcuidle suffix, for example, as
in trace_opal_entry_rcuidle(). If not:
Acked-by: Paul E. McKenney paul
On Tue, Oct 01, 2013 at 12:05:03PM +1000, Benjamin Herrenschmidt wrote:
On Mon, 2013-09-30 at 17:56 -0700, Linus Torvalds wrote:
On Mon, Sep 30, 2013 at 5:36 PM, Michael Neuling mi...@neuling.org wrote:
The scary part is that we to make all register volatile. You were not
that keen on
On Tue, Oct 01, 2013 at 02:52:28PM +1000, Michael Neuling wrote:
Well we don't have to, I think Mikey wasn't totally clear about that
making all registers volatile business :-) This is just something we
need to handle in assembly if we are going to reclaim the suspended
transaction.
On Tue, Oct 01, 2013 at 05:16:54AM -0700, Paul E. McKenney wrote:
On Tue, Oct 01, 2013 at 02:52:28PM +1000, Michael Neuling wrote:
Well we don't have to, I think Mikey wasn't totally clear about that
making all registers volatile business :-) This is just something we
need to handle
On Mon, Oct 28, 2013 at 02:26:34PM +0100, Peter Zijlstra wrote:
On Mon, Oct 28, 2013 at 02:38:29PM +0200, Victor Kaplansky wrote:
2013/10/25 Peter Zijlstra pet...@infradead.org:
On Wed, Oct 23, 2013 at 03:19:51PM +0100, Frederic Weisbecker wrote:
I would argue for
READ
On Mon, Oct 28, 2013 at 10:58:58PM +0200, Victor Kaplansky wrote:
Oleg Nesterov o...@redhat.com wrote on 10/28/2013 10:17:35 PM:
mb(); // : do we really need it? I think yes.
Oh, it is hard to argue with feelings. Also, it is easy to be on
conservative side and put the
On Wed, Oct 30, 2013 at 04:51:16PM +0100, Peter Zijlstra wrote:
On Wed, Oct 30, 2013 at 03:28:54PM +0200, Victor Kaplansky wrote:
one of the authors of Documentation/memory-barriers.txt is on cc: list ;-)
Disclaimer: it is anyway impossible to prove lack of *any* problem.
Having said
On Wed, Oct 30, 2013 at 03:28:54PM +0200, Victor Kaplansky wrote:
Paul E. McKenney paul...@linux.vnet.ibm.com wrote on 10/30/2013
11:27:25 AM:
If you were to back up that insistence with a description of the
orderings
you are relying on, why other orderings are not important, and how
On Thu, Oct 31, 2013 at 10:04:57AM +0100, Peter Zijlstra wrote:
On Wed, Oct 30, 2013 at 09:32:58PM -0700, Paul E. McKenney wrote:
Before C/C++11, the closest thing to such a prohibition is use of
volatile, for example, ACCESS_ONCE(). Even in C/C++11, you have to
use atomics to get anything
On Thu, Oct 31, 2013 at 04:19:55PM +0100, Peter Zijlstra wrote:
On Thu, Oct 31, 2013 at 08:07:56AM -0700, Paul E. McKenney wrote:
On Thu, Oct 31, 2013 at 10:04:57AM +0100, Peter Zijlstra wrote:
On Wed, Oct 30, 2013 at 09:32:58PM -0700, Paul E. McKenney wrote:
Before C/C++11, the closest
On Thu, Oct 31, 2013 at 11:59:21AM +0200, Victor Kaplansky wrote:
Paul E. McKenney paul...@linux.vnet.ibm.com wrote on 10/31/2013
06:32:58 AM:
If you want to play the omit memory barriers game, then proving a
negative is in fact the task before you.
Generally it is not fair. Otherwise
On Wed, Oct 30, 2013 at 12:25:26PM +0100, Peter Zijlstra wrote:
On Wed, Oct 30, 2013 at 02:27:25AM -0700, Paul E. McKenney wrote:
On Mon, Oct 28, 2013 at 10:58:58PM +0200, Victor Kaplansky wrote:
Oleg Nesterov o...@redhat.com wrote on 10/28/2013 10:17:35 PM:
mb(); //
On Wed, Oct 30, 2013 at 04:52:05PM +0200, Victor Kaplansky wrote:
Peter Zijlstra pet...@infradead.org wrote on 10/30/2013 01:25:26 PM:
Also, I'm not entirely sure on C, that too seems like a dependency, we
simply cannot read the buffer @tail before we've read the tail itself,
now can we?
On Fri, Nov 01, 2013 at 05:11:29PM +0100, Peter Zijlstra wrote:
On Wed, Oct 30, 2013 at 11:40:15PM -0700, Paul E. McKenney wrote:
void kbuf_write(int sz, void *buf)
{
u64 tail = ACCESS_ONCE(ubuf-tail); /* last location userspace read */
u64 offset = kbuf-head; /* we already know
On Fri, Nov 01, 2013 at 04:25:42PM +0200, Victor Kaplansky wrote:
Paul E. McKenney paul...@linux.vnet.ibm.com wrote on 10/31/2013
08:40:15 AM:
void ubuf_read(void)
{
u64 head, tail;
tail = ACCESS_ONCE(ubuf-tail);
head = ACCESS_ONCE(ubuf-head
On Fri, Nov 01, 2013 at 03:12:58PM +0200, Victor Kaplansky wrote:
Paul E. McKenney paul...@linux.vnet.ibm.com wrote on 10/31/2013
08:16:02 AM:
BTW, it is why you also don't need ACCESS_ONCE() around @tail, but only
around
@head read.
Just to be sure, that we are talking about
On Fri, Nov 01, 2013 at 11:30:17AM +0100, Peter Zijlstra wrote:
On Fri, Nov 01, 2013 at 02:28:14AM -0700, Paul E. McKenney wrote:
This is a completely untenable position.
Indeed it is!
C/C++ never was intended to be used for parallel programming,
And yet pretty much all kernels
On Fri, Nov 01, 2013 at 06:06:58PM +0200, Victor Kaplansky wrote:
Paul E. McKenney paul...@linux.vnet.ibm.com wrote on 10/31/2013
05:25:43 PM:
I really don't care about fair -- I care instead about the kernel
working reliably.
Though I don't see how putting a memory barrier without deep
[ Adding David Howells, Lech Fomicki, and Mark Batty on CC for their
thoughts given previous discussions. ]
On Sat, Nov 02, 2013 at 09:36:18AM -0700, Paul E. McKenney wrote:
On Fri, Nov 01, 2013 at 03:12:58PM +0200, Victor Kaplansky wrote:
Paul E. McKenney paul...@linux.vnet.ibm.com wrote
On Fri, Nov 01, 2013 at 05:18:19PM +0100, Peter Zijlstra wrote:
On Wed, Oct 30, 2013 at 11:40:15PM -0700, Paul E. McKenney wrote:
The dependency you are talking about is via the if statement?
Even C/C++11 is not required to respect control dependencies.
This one is a bit annoying
On Fri, Nov 01, 2013 at 03:56:34PM +0100, Peter Zijlstra wrote:
On Wed, Oct 30, 2013 at 11:40:15PM -0700, Paul E. McKenney wrote:
Now the whole crux of the question is if we need barrier A at all, since
the STORES issued by the @buf writes are dependent on the ubuf-tail
read
On Sat, Nov 02, 2013 at 10:32:39AM -0700, Paul E. McKenney wrote:
On Fri, Nov 01, 2013 at 03:56:34PM +0100, Peter Zijlstra wrote:
On Wed, Oct 30, 2013 at 11:40:15PM -0700, Paul E. McKenney wrote:
Now the whole crux of the question is if we need barrier A at all, since
the STORES issued
On Sun, Nov 03, 2013 at 09:01:24PM +0100, Peter Zijlstra wrote:
On Sun, Nov 03, 2013 at 10:08:14AM -0800, Linus Torvalds wrote:
On Sun, Nov 3, 2013 at 7:17 AM, Peter Zijlstra pet...@infradead.org wrote:
On Sun, Nov 03, 2013 at 06:40:17AM -0800, Paul E. McKenney wrote
On Mon, Nov 04, 2013 at 07:59:23AM +1100, Benjamin Herrenschmidt wrote:
On Sun, 2013-11-03 at 16:17 +0100, Peter Zijlstra wrote:
On Sun, Nov 03, 2013 at 06:40:17AM -0800, Paul E. McKenney wrote:
If there was an smp_tmb(), I would likely use it in rcu_assign_pointer().
Well, I'm
On Mon, Nov 04, 2013 at 10:07:44AM +0100, Peter Zijlstra wrote:
On Sat, Nov 02, 2013 at 08:20:48AM -0700, Paul E. McKenney wrote:
On Fri, Nov 01, 2013 at 11:30:17AM +0100, Peter Zijlstra wrote:
Furthermore there's a gazillion parallel userspace programs.
Most of which have very
1 - 100 of 388 matches
Mail list logo
