Fix ppc 32 build failure as reported here:
http://kisskb.ellerman.id.au/kisskb/buildresult/11663513/
The error is that pci_32.o was not being built for PPC_32. Fix error by adding
it in the Makefile. Tested using the ppc cross compiler.
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
On Mon, Aug 18, 2014 at 3:28 PM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
Hi Pranith,
On Mon, Aug 18, 2014 at 9:01 PM, Pranith Kumar bobby.pr...@gmail.com wrote:
Fix ppc 32 build failure as reported here:
http://kisskb.ellerman.id.au/kisskb/buildresult/11663513/
| arch/powerpc
On Mon, Aug 18, 2014 at 4:57 PM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
Note that PowerPC supports multi-platform kernels.
A kernel with PPC_PSERIES and something else with PCI may still want to
have floppy support.
OK, I tested with your change and it works. I needed to make one more
which depends on
ARCH_MAY_HAVE_PC_FDC which is in-turn enabled if PPC_PSERIES=n.
The following commit changes the dependency so that ARCH_MAY_HAVE_PC_FDC is
dependent exclusively on PCI since otherwise it will not compile.
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
Reported-by: Geert
as vgacon_remap_base is exported only when
CONFIG_VGA_CONSOLE=y. Fix the error by making FB_VBA16 depend on
CONFIG_VGA_CONSOLE.
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
Reported-by: Geert Uytterhoeven ge...@linux-m68k.org
CC: Andrew Morton a...@linux-foundation.org
---
drivers/video/fbdev/Kconfig | 2
On Mon, Aug 18, 2014 at 5:28 PM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
Digging a bit deeper: There's no code left in arch/powerpc that actually
sets vgacon_remap_base, so it's not gonna work anyway.
It seems vga16 support on PPC died with the removal of arch/ppc/.
OK. I will remove
It was noted by Geert that in PPC, no one is setting vgacon_remap_base because
of which it working on PPC is suspect.
Fix the build failure by disabling vga16fb on PPC.
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
Reported-by: Geert Uytterhoeven ge...@linux-m68k.org
CC: Andrew Morton a...@linux
Fix building errors occuring due to a missing export of flush_icache_range() in
architectures missing the export.
Signed-off-by: Pranith Kumar
Reported-by: Geert Uytterhoeven
CC: Andrew Morton
---
arch/arc/mm/cache_arc700.c |1 +
arch/blackfin/include/asm/cacheflush.h |1
Fix building errors occuring due to a missing export of flush_icache_range() in
architectures missing the export.
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
Reported-by: Geert Uytterhoeven ge...@linux-m68k.org
CC: Andrew Morton a...@linux-foundation.org
---
arch/arc/mm/cache_arc700.c
On Mon, Aug 11, 2014 at 6:49 PM, Paul E. McKenney
wrote:
> From: "Paul E. McKenney"
>
> Currently TASKS_RCU would ignore a CPU running a task in nohz_full=
> usermode execution. There would be neither a context switch nor a
> scheduling-clock interrupt to tell TASKS_RCU that the task in
On Mon, Aug 11, 2014 at 6:49 PM, Paul E. McKenney
wrote:
> From: "Paul E. McKenney"
>
> It is expected that many sites will have CONFIG_TASKS_RCU=y, but
> will never actually invoke call_rcu_tasks(). For such sites, creating
> rcu_tasks_kthread() at boot is wasteful. This commit therefore
On Thu, Aug 14, 2014 at 5:55 PM, Paul E. McKenney
wrote:
> On Thu, Aug 14, 2014 at 05:42:06PM -0400, Pranith Kumar wrote:
>> On Mon, Aug 11, 2014 at 6:48 PM, Paul E. McKenney
>> wrote:
>> > From: "Paul E. McKenney"
>> >
>> > The current RC
On Mon, Aug 11, 2014 at 6:48 PM, Paul E. McKenney
wrote:
> From: "Paul E. McKenney"
>
> The current RCU-tasks implementation uses strict polling to detect
> callback arrivals. This works quite well, but is not so good for
> energy efficiency. This commit therefore replaces the strict polling
>
On Mon, Aug 11, 2014 at 6:48 PM, Paul E. McKenney
wrote:
> From: "Paul E. McKenney"
>
> This commit adds a three-minute RCU-tasks stall warning. The actual
> time is controlled by the boot/sysfs parameter rcu_task_stall_timeout,
> with values less than or equal to zero disabling the stall
On Mon, Aug 11, 2014 at 6:48 PM, Paul E. McKenney
wrote:
> From: "Paul E. McKenney"
>
> This commit adds torture tests for RCU-tasks. It also fixes a bug that
> would segfault for an RCU flavor lacking a callback-barrier function.
>
> Signed-off-by: Paul E. McKenney
> Reviewed-by: Josh
On Mon, Aug 11, 2014 at 6:48 PM, Paul E. McKenney
wrote:
> From: "Paul E. McKenney"
>
> This commit adds a new RCU-tasks flavor of RCU, which provides
> call_rcu_tasks(). This RCU flavor's quiescent states are voluntary
> context switch (not preemption!), userspace execution, and the idle loop.
On Mon, Aug 11, 2014 at 6:48 PM, Paul E. McKenney
wrote:
> From: Steven Rostedt
>
> This commit exports the RCU-tasks APIs, call_rcu_tasks(),
> synchronize_rcu_tasks(), and rcu_barrier_tasks(), to GPL-licensed
> kernel modules.
Only two of these are being exported in this patch. Patch 1 is
On Mon, Aug 11, 2014 at 6:48 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
From: Steven Rostedt rost...@goodmis.org
This commit exports the RCU-tasks APIs, call_rcu_tasks(),
synchronize_rcu_tasks(), and rcu_barrier_tasks(), to GPL-licensed
kernel modules.
Only two of these are being
On Mon, Aug 11, 2014 at 6:48 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
From: Paul E. McKenney paul...@linux.vnet.ibm.com
This commit adds a new RCU-tasks flavor of RCU, which provides
call_rcu_tasks(). This RCU flavor's quiescent states are voluntary
context switch (not
On Mon, Aug 11, 2014 at 6:48 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
From: Paul E. McKenney paul...@linux.vnet.ibm.com
This commit adds torture tests for RCU-tasks. It also fixes a bug that
would segfault for an RCU flavor lacking a callback-barrier function.
Signed-off-by:
On Mon, Aug 11, 2014 at 6:48 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
From: Paul E. McKenney paul...@linux.vnet.ibm.com
This commit adds a three-minute RCU-tasks stall warning. The actual
time is controlled by the boot/sysfs parameter rcu_task_stall_timeout,
with values less
On Mon, Aug 11, 2014 at 6:48 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
From: Paul E. McKenney paul...@linux.vnet.ibm.com
The current RCU-tasks implementation uses strict polling to detect
callback arrivals. This works quite well, but is not so good for
energy efficiency. This
On Mon, Aug 11, 2014 at 6:49 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
From: Paul E. McKenney paul...@linux.vnet.ibm.com
It is expected that many sites will have CONFIG_TASKS_RCU=y, but
will never actually invoke call_rcu_tasks(). For such sites, creating
rcu_tasks_kthread() at
On Mon, Aug 11, 2014 at 6:49 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
From: Paul E. McKenney paul...@linux.vnet.ibm.com
Currently TASKS_RCU would ignore a CPU running a task in nohz_full=
usermode execution. There would be neither a context switch nor a
scheduling-clock
On Wed, Aug 13, 2014 at 8:35 PM, Paul E. McKenney
wrote:
>>
>> If the stores to 'b' differ, then there is no issue. Why not document how to
>> avoid re-ordering in the case where both the stores are the same? In that
>> case
>> using a stronger barrier like mb() should be sufficient for both the
>
> memory-barriers: Fix description of 2-legged-if-based control dependencies
>
> Sad to say, current compilers really will hoist identical stores from both
> branches of an "if" statement to precede the conditional. This commit
> theref
On Tue, Aug 12, 2014 at 12:39 PM, Randy Dunlap wrote:
> On 08/11/14 10:22, Christoph Lameter wrote:
>> On Mon, 11 Aug 2014, Pranith Kumar wrote:
>>
>>> Update the description for per cpu operations to clarify use cases
>>> of this_cpu operations and add
Match the declaration of runqueues with the definition.
Signed-off-by: Pranith Kumar
---
kernel/sched/sched.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 579712f..4c2b87f 100644
--- a/kernel/sched/sched.h
+++ b/kernel
jiffies_64 is defined with different section attribute. This commit changes the
extern definition to be the same as the actual definition.
Signed-off-by: Pranith Kumar
---
include/linux/jiffies.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/jiffies.h b
jiffies_64 is defined with different section attribute. This commit changes the
extern definition to be the same as the actual definition.
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
---
include/linux/jiffies.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include
Match the declaration of runqueues with the definition.
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
---
kernel/sched/sched.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 579712f..4c2b87f 100644
--- a/kernel/sched
On Tue, Aug 12, 2014 at 12:39 PM, Randy Dunlap rdun...@infradead.org wrote:
On 08/11/14 10:22, Christoph Lameter wrote:
On Mon, 11 Aug 2014, Pranith Kumar wrote:
Update the description for per cpu operations to clarify use cases
of this_cpu operations and add considerations for remote access
both
branches of an if statement to precede the conditional. This commit
therefore updates the description of control dependencies to reflect this
ugly reality.
Reported-by: Pranith Kumar bobby.pr...@gmail.com
Reported-by: Peter Zijlstra pet...@infradead.org
Signed-off-by: Paul E. McKenney
On Wed, Aug 13, 2014 at 8:35 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
If the stores to 'b' differ, then there is no issue. Why not document how to
avoid re-ordering in the case where both the stores are the same? In that
case
using a stronger barrier like mb() should be
Remove a duplicate const qualifier
Signed-off-by: Pranith Kumar
---
arch/x86/kernel/rtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/rtc.c b/arch/x86/kernel/rtc.c
index ca9622a..fe3dbfe 100644
--- a/arch/x86/kernel/rtc.c
+++ b/arch/x86/kernel/rtc.c
using
rcu_gp_kthread_wake() function.
Signed-off-by: Pranith Kumar
CC: Mathieu Desnoyers
---
kernel/rcu/tree.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index b63517c..6b68d2d 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/
On Tue, Aug 12, 2014 at 1:55 AM, Peter Zijlstra wrote:
> On Mon, Aug 11, 2014 at 06:51:41PM -0400, Pranith Kumar wrote:
>> jiffies is declared as a volatile variable. Therefore it is not neccessary to
>> use ACCESS_ONCE() while reading it.
>
> It also doesn't hurt and it doc
On Tue, Aug 12, 2014 at 1:55 AM, Peter Zijlstra pet...@infradead.org wrote:
On Mon, Aug 11, 2014 at 06:51:41PM -0400, Pranith Kumar wrote:
jiffies is declared as a volatile variable. Therefore it is not neccessary to
use ACCESS_ONCE() while reading it.
It also doesn't hurt and it documents
rcu_gp_kthread_wake() function.
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
CC: Mathieu Desnoyers mathieu.desnoy...@efficios.com
---
kernel/rcu/tree.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index b63517c..6b68d2d 100644
Remove a duplicate const qualifier
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
---
arch/x86/kernel/rtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/rtc.c b/arch/x86/kernel/rtc.c
index ca9622a..fe3dbfe 100644
--- a/arch/x86/kernel/rtc.c
+++ b/arch
Minor corrections in memory-barriers.txt document.
Signed-off-by: Pranith Kumar
---
Documentation/memory-barriers.txt | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/memory-barriers.txt
b/Documentation/memory-barriers.txt
index abec3f9..41a6c9c
In the provably false case, add barrier() in both the legs of the if() condition
to provide ordering.
Signed-off-by: Pranith Kumar
---
Documentation/memory-barriers.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/memory-barriers.txt
b/Documentation/memory-barriers.txt
jiffies is declared as a volatile variable. Therefore it is not neccessary to
use ACCESS_ONCE() while reading it.
Signed-off-by: Pranith Kumar
---
kernel/sched/core.c | 2 +-
kernel/sched/proc.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/sched/core.c b
er-intel.h.
This commit reverts the previous commit and removes the definition from
compiler.h
Signed-off-by: Pranith Kumar
---
include/linux/compiler-intel.h | 3 +++
include/linux/compiler.h | 5 -
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/include/linux/compiler-intel.h b/inc
Update the description for per cpu operations to clarify use cases
of this_cpu operations and add considerations for remote access.
Signed-off-by: Pranith Kumar
Signed-off-by: Christoph Lameter
---
Documentation/this_cpu_ops.txt | 213 +
1 file changed
reverts the previous commit and removes the definition from
compiler.h
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
---
include/linux/compiler-intel.h | 3 +++
include/linux/compiler.h | 5 -
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/include/linux/compiler
Minor corrections in memory-barriers.txt document.
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
---
Documentation/memory-barriers.txt | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/memory-barriers.txt
b/Documentation/memory-barriers.txt
index
In the provably false case, add barrier() in both the legs of the if() condition
to provide ordering.
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
---
Documentation/memory-barriers.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/memory-barriers.txt
b/Documentation
jiffies is declared as a volatile variable. Therefore it is not neccessary to
use ACCESS_ONCE() while reading it.
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
---
kernel/sched/core.c | 2 +-
kernel/sched/proc.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel
Update the description for per cpu operations to clarify use cases
of this_cpu operations and add considerations for remote access.
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
Signed-off-by: Christoph Lameter c...@linux.com
---
Documentation/this_cpu_ops.txt | 213
1CFB236]
> X-RcptDomain: telfort.nl
>
> The question:
>
> Nick/Nickolas Krause: xerofo...@gmail.com = xerofoi...@gmail.com =
> xerofoi...@gmail.com
>
> == (???) (conjecture A)
>
> Pranith Kumar: bobby.pr...@gmail.com
>
> == (???) (conjecture B)
>
>
=[B98F0610:01CFB236]
X-RcptDomain: telfort.nl
The question:
Nick/Nickolas Krause: xerofo...@gmail.com = xerofoi...@gmail.com =
xerofoi...@gmail.com
== (???) (conjecture A)
Pranith Kumar: bobby.pr...@gmail.com
== (???) (conjecture B)
Pranith Kumar: pran...@gatech.edu
Indication
Please note, this also fixes the following build error on sparc64
http://kisskb.ellerman.id.au/kisskb/buildresult/11607883/
On Tue, Aug 5, 2014 at 12:27 PM, Pranith Kumar wrote:
> The following patch fixes a build error on sparc32. I think it should go to
> stable 3.16.
>
> Remov
/unmap(). Fix this build error by adding these
prototypes.
Reported-by: Geert Uytterhoeven
Signed-off-by: Pranith Kumar
---
arch/sh/include/asm/io_noioport.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/sh/include/asm/io_noioport.h
b/arch/sh/include/asm/io_noioport.h
-by: Geert Uytterhoeven
Signed-off-by: Pranith Kumar
---
arch/sh/include/asm/io_noioport.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/sh/include/asm/io_noioport.h
b/arch/sh/include/asm/io_noioport.h
index 4d48f14..c727e6d 100644
--- a/arch/sh/include/asm/io_noioport.h
+++ b
.h:17,
from arch/sparc/include/asm/atomic.h:6,
from drivers/staging/lustre/lustre/obdclass/class_obd.c:38
Signed-off-by: Pranith Kumar
CC: sta...@vger.kernel.org
---
drivers/staging/lustre/lustre/obdclass/class_obd.c | 2 +-
1 file changed, 1 insertion(+), 1
On Tue, Aug 5, 2014 at 3:32 AM, Peter Zijlstra wrote:
>>
>> 685 This transformation loses the ordering between the load from variable 'a'
>> 686 and the store to variable 'b'. If you are relying on this ordering, you
>> 687 should do something like the following:
>> 688
>> 689 q =
On Tue, Aug 5, 2014 at 3:32 AM, Peter Zijlstra pet...@infradead.org wrote:
685 This transformation loses the ordering between the load from variable 'a'
686 and the store to variable 'b'. If you are relying on this ordering, you
687 should do something like the following:
688
689 q
.h:17,
from arch/sparc/include/asm/atomic.h:6,
from drivers/staging/lustre/lustre/obdclass/class_obd.c:38
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
CC: sta...@vger.kernel.org
---
drivers/staging/lustre/lustre/obdclass/class_obd.c | 2 +-
1 file changed, 1
-by: Geert Uytterhoeven ge...@linux-m68k.org
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
---
arch/sh/include/asm/io_noioport.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/sh/include/asm/io_noioport.h
b/arch/sh/include/asm/io_noioport.h
index 4d48f14..c727e6d 100644
/unmap(). Fix this build error by adding these
prototypes.
Reported-by: Geert Uytterhoeven ge...@linux-m68k.org
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
---
arch/sh/include/asm/io_noioport.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/sh/include/asm
Please note, this also fixes the following build error on sparc64
http://kisskb.ellerman.id.au/kisskb/buildresult/11607883/
On Tue, Aug 5, 2014 at 12:27 PM, Pranith Kumar bobby.pr...@gmail.com wrote:
The following patch fixes a build error on sparc32. I think it should go to
stable 3.16
On Mon, Aug 4, 2014 at 2:52 PM, Paul E. McKenney
wrote:
>>
>> Given that there is an explicit barrier() in both the branches of
>> if/else statement, how can the above transformation happen? The
>> compiler cannot just remove the barrier(), right?
>
> No, the compiler cannot just remove the
The section "Control Dependencies" in memory-barriers.txt has the
following text:
662 In addition, you need to be careful what you do with the local variable 'q',
663 otherwise the compiler might be able to guess the value and again remove
664 the needed conditional. For example:
665
666
On Mon, Aug 4, 2014 at 6:48 AM, Joe Thornber wrote:
> On Sun, Aug 03, 2014 at 12:01:17AM -0400, Pranith Kumar wrote:
>> Also dm_cblock_t is uint32_t, but atomic_t changes that to int. You
>> should correct that to atomic64_t to preserve original semantics.
>
> atomic_t used
On Mon, Aug 4, 2014 at 6:48 AM, Joe Thornber thorn...@redhat.com wrote:
On Sun, Aug 03, 2014 at 12:01:17AM -0400, Pranith Kumar wrote:
Also dm_cblock_t is uint32_t, but atomic_t changes that to int. You
should correct that to atomic64_t to preserve original semantics.
atomic_t used to have
The section Control Dependencies in memory-barriers.txt has the
following text:
662 In addition, you need to be careful what you do with the local variable 'q',
663 otherwise the compiler might be able to guess the value and again remove
664 the needed conditional. For example:
665
666 q
On Mon, Aug 4, 2014 at 2:52 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
Given that there is an explicit barrier() in both the branches of
if/else statement, how can the above transformation happen? The
compiler cannot just remove the barrier(), right?
No, the compiler cannot just
On Sun, Aug 3, 2014 at 1:17 AM, Pranith Kumar wrote:
> On 08/03/2014 12:57 AM, Pranith Kumar wrote:
>> On 08/03/2014 12:46 AM, Pranith Kumar wrote:
>>> On 08/02/2014 10:10 PM, Pranith Kumar wrote:
>>>> Corrently adding Anssi this time.
>>>>
>>&
On 08/03/2014 12:57 AM, Pranith Kumar wrote:
> On 08/03/2014 12:46 AM, Pranith Kumar wrote:
>> On 08/02/2014 10:10 PM, Pranith Kumar wrote:
>>> Corrently adding Anssi this time.
>>>
>>> On Sat, Aug 2, 2014 at 10:00 PM, Pranith Kumar
>>> wrote:
>&g
On 08/03/2014 12:46 AM, Pranith Kumar wrote:
> On 08/02/2014 10:10 PM, Pranith Kumar wrote:
>> Corrently adding Anssi this time.
>>
>> On Sat, Aug 2, 2014 at 10:00 PM, Pranith Kumar wrote:
>>> Hello Anssi, Joe, Mike,
>>>
>>> I just found you
On 08/02/2014 10:10 PM, Pranith Kumar wrote:
> Corrently adding Anssi this time.
>
> On Sat, Aug 2, 2014 at 10:00 PM, Pranith Kumar wrote:
>> Hello Anssi, Joe, Mike,
>>
>> I just found your patch in the latest rc and wanted to ask a few
>> questions. I am not
On Sat, Aug 2, 2014 at 11:33 PM, Anssi Hannula wrote:
> 03.08.2014, 05:10, Pranith Kumar kirjoitti:
>> Corrently adding Anssi this time.
>>
>> On Sat, Aug 2, 2014 at 10:00 PM, Pranith Kumar wrote:
>>> Hello Anssi, Joe, Mike,
>
> Hi,
>
>>> I j
Corrently adding Anssi this time.
On Sat, Aug 2, 2014 at 10:00 PM, Pranith Kumar wrote:
> Hello Anssi, Joe, Mike,
>
> I just found your patch in the latest rc and wanted to ask a few
> questions. I am not sure how this patch helps at all other than luck in
> that dm_cblock_t
Correctly adding Anssi this time.
On Sat, Aug 2, 2014 at 10:00 PM, Pranith Kumar wrote:
> Hello Anssi, Joe, Mike,
>
> I just found your patch in the latest rc and wanted to ask a few
> questions. I am not sure how this patch helps at all other than luck in
> that dm_cblock_t
Hello Anssi, Joe, Mike,
I just found your patch in the latest rc and wanted to ask a few
questions. I am not sure how this patch helps at all other than luck in
that dm_cblock_t type is of type int32_t, which should guarantee that it
is atomic on most platforms. Which begs the question, what
Signed-off-by: Pranith Kumar
CC: Christoph Lameter
---
v4: more updates from Christoph Lameter
v3: clearly mention that remote write access is discouraged
v2: updated with comments from Christoph Lameter
Documentation/this_cpu_ops.txt | 174 ++---
1 file
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
CC: Christoph Lameter c...@linux.com
---
v4: more updates from Christoph Lameter
v3: clearly mention that remote write access is discouraged
v2: updated with comments from Christoph Lameter
Documentation/this_cpu_ops.txt | 174
Hello Anssi, Joe, Mike,
I just found your patch in the latest rc and wanted to ask a few
questions. I am not sure how this patch helps at all other than luck in
that dm_cblock_t type is of type int32_t, which should guarantee that it
is atomic on most platforms. Which begs the question, what
Correctly adding Anssi this time.
On Sat, Aug 2, 2014 at 10:00 PM, Pranith Kumar bobby.pr...@gmail.com wrote:
Hello Anssi, Joe, Mike,
I just found your patch in the latest rc and wanted to ask a few
questions. I am not sure how this patch helps at all other than luck in
that dm_cblock_t type
Corrently adding Anssi this time.
On Sat, Aug 2, 2014 at 10:00 PM, Pranith Kumar bobby.pr...@gmail.com wrote:
Hello Anssi, Joe, Mike,
I just found your patch in the latest rc and wanted to ask a few
questions. I am not sure how this patch helps at all other than luck in
that dm_cblock_t type
On Sat, Aug 2, 2014 at 11:33 PM, Anssi Hannula anssi.hann...@iki.fi wrote:
03.08.2014, 05:10, Pranith Kumar kirjoitti:
Corrently adding Anssi this time.
On Sat, Aug 2, 2014 at 10:00 PM, Pranith Kumar bobby.pr...@gmail.com wrote:
Hello Anssi, Joe, Mike,
Hi,
I just found your patch
On 08/02/2014 10:10 PM, Pranith Kumar wrote:
Corrently adding Anssi this time.
On Sat, Aug 2, 2014 at 10:00 PM, Pranith Kumar bobby.pr...@gmail.com wrote:
Hello Anssi, Joe, Mike,
I just found your patch in the latest rc and wanted to ask a few
questions. I am not sure how this patch helps
On 08/03/2014 12:46 AM, Pranith Kumar wrote:
On 08/02/2014 10:10 PM, Pranith Kumar wrote:
Corrently adding Anssi this time.
On Sat, Aug 2, 2014 at 10:00 PM, Pranith Kumar bobby.pr...@gmail.com wrote:
Hello Anssi, Joe, Mike,
I just found your patch in the latest rc and wanted to ask a few
On 08/03/2014 12:57 AM, Pranith Kumar wrote:
On 08/03/2014 12:46 AM, Pranith Kumar wrote:
On 08/02/2014 10:10 PM, Pranith Kumar wrote:
Corrently adding Anssi this time.
On Sat, Aug 2, 2014 at 10:00 PM, Pranith Kumar bobby.pr...@gmail.com
wrote:
Hello Anssi, Joe, Mike,
I just found your
On Sun, Aug 3, 2014 at 1:17 AM, Pranith Kumar bobby.pr...@gmail.com wrote:
On 08/03/2014 12:57 AM, Pranith Kumar wrote:
On 08/03/2014 12:46 AM, Pranith Kumar wrote:
On 08/02/2014 10:10 PM, Pranith Kumar wrote:
Corrently adding Anssi this time.
On Sat, Aug 2, 2014 at 10:00 PM, Pranith Kumar
cu_init_nohz()
> that properly initializes the no-CBs CPUs.
>
> Note that kernels built with CONFIG_RCU_NOCB_CPU_ALL=y or with
> CONFIG_RCU_NOCB_CPU=n do not exhibit this bug. Neither do kernels
> booted without the nohz_full= boot parameter.
>
> Signed-off-by: Paul E. McKenney
On Mon, Jul 28, 2014 at 10:58 AM, Pranith Kumar wrote:
> Commit fbce7497ee5a ("rcu: Parallelize and economize NOCB kthread wakeups")
>
> tries to reduce the wake up overhead by creating leader and follower nocb
> kthreads.
>
> One thing overlooked here is that all t
n the wait queue, we also try to wake
up the follower threads because of which there is still wake up overhead.
This commit tries to avoid that by using separate wait queues for the leaders
and
followers.
Signed-off-by: Pranith Kumar
---
kernel/rcu/tree.h| 3 ++-
kernel/rcu/tree_plu
queue, we also try to wake
up the follower threads because of which there is still wake up overhead.
This commit tries to avoid that by using separate wait queues for the leaders
and
followers.
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
---
kernel/rcu/tree.h| 3 ++-
kernel/rcu
On Mon, Jul 28, 2014 at 10:58 AM, Pranith Kumar bobby.pr...@gmail.com wrote:
Commit fbce7497ee5a (rcu: Parallelize and economize NOCB kthread wakeups)
tries to reduce the wake up overhead by creating leader and follower nocb
kthreads.
One thing overlooked here is that all the kthreads wait
with CONFIG_RCU_NOCB_CPU_ALL=y or with
CONFIG_RCU_NOCB_CPU=n do not exhibit this bug. Neither do kernels
booted without the nohz_full= boot parameter.
Signed-off-by: Paul E. McKenney paul...@linux.vnet.ibm.com
Reviewed-by: Pranith Kumar bobby.pr...@gmail.com
diff --git a/include/linux/rcupdate.h b
On Sun, Jul 27, 2014 at 7:49 PM, Mathieu Desnoyers
wrote:
> - Original Message -
>> From: "Pranith Kumar"
>> To: "Paul E. McKenney" , "Josh Triplett"
>> , "Steven Rostedt"
>> , "Mathieu Desnoyers" ,
>> &
rcu_gp_kthread_wake() to conditionally wake up the grace period kthreads.
Hence this commit tries to avoid calling wake_up() whenever we can by using
rcu_gp_kthread_wake() function.
Signed-off-by: Pranith Kumar
---
kernel/rcu/tree.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git
On Sun, Jul 27, 2014 at 12:29 PM, Paul E. McKenney
wrote:
> On Sun, Jul 27, 2014 at 11:55:38AM -0400, Pranith Kumar wrote:
>> Hi Paul,
>>
>> On Fri, Jul 25, 2014 at 6:47 PM, Paul E. McKenney
>> wrote:
>> > On Fri, Jul 25, 2014 at 04:19:43PM -0400, Pranith Ku
Hi Paul,
On Fri, Jul 25, 2014 at 6:47 PM, Paul E. McKenney
wrote:
> On Fri, Jul 25, 2014 at 04:19:43PM -0400, Pranith Kumar wrote:
>>
>> I checked all the locations where gp_flags is being updated and the
>> root node lock is held in all the cases.
>> So I guess we
Hi Paul,
On Fri, Jul 25, 2014 at 6:47 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
On Fri, Jul 25, 2014 at 04:19:43PM -0400, Pranith Kumar wrote:
I checked all the locations where gp_flags is being updated and the
root node lock is held in all the cases.
So I guess we can remove
On Sun, Jul 27, 2014 at 12:29 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
On Sun, Jul 27, 2014 at 11:55:38AM -0400, Pranith Kumar wrote:
Hi Paul,
On Fri, Jul 25, 2014 at 6:47 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
On Fri, Jul 25, 2014 at 04:19:43PM -0400, Pranith
rcu_gp_kthread_wake() to conditionally wake up the grace period kthreads.
Hence this commit tries to avoid calling wake_up() whenever we can by using
rcu_gp_kthread_wake() function.
Signed-off-by: Pranith Kumar bobby.pr...@gmail.com
---
kernel/rcu/tree.c | 10 --
1 file changed, 8 insertions(+), 2
On Sun, Jul 27, 2014 at 7:49 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
- Original Message -
From: Pranith Kumar bobby.pr...@gmail.com
To: Paul E. McKenney paul...@linux.vnet.ibm.com, Josh Triplett
j...@joshtriplett.org, Steven Rostedt
rost...@goodmis.org, Mathieu
501 - 600 of 984 matches
Mail list logo
