WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-changelog

[Xen-changelog] [xen-unstable] [LINUX] Fix interaction between idle loop

To: xen-changelog@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-changelog] [xen-unstable] [LINUX] Fix interaction between idle loop and RCU subsystem.
From: Xen patchbot-unstable <patchbot-unstable@xxxxxxxxxxxxxxxxxxx>
Date: Mon, 12 Jun 2006 19:05:23 +0000
Delivery-date: Mon, 12 Jun 2006 12:07:10 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-changelog-request@lists.xensource.com?subject=help>
List-id: BK change log <xen-changelog.lists.xensource.com>
List-post: <mailto:xen-changelog@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-changelog>, <mailto:xen-changelog-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-changelog>, <mailto:xen-changelog-request@lists.xensource.com?subject=unsubscribe>
Reply-to: xen-devel@xxxxxxxxxxxxxxxxxxx
Sender: xen-changelog-bounces@xxxxxxxxxxxxxxxxxxx
# HG changeset patch
# User kaf24@xxxxxxxxxxxxxxxxxxxx
# Node ID c230dbe793d623d67ca1d486c0c1a8db5c7cab94
# Parent  34ff26fb2240b836057de452abdd740e8122a584
[LINUX] Fix interaction between idle loop and RCU subsystem.

There is a problem with the current implementation of stop_hz_timer in
arch/i386/kernel/time-xen.c where the hz timer can be stopped on a CPU
which has RCU callbacks pending.

This patch backports a new RCU API created to fix this problem for the
s390 implementation of stop_hz_timer and also updates the time-xen.c
implementation of stop_hz_timer to call the new API.

Signed-off-by: Harry Butterworth <butterwo@xxxxxxxxxx>
---
 linux-2.6-xen-sparse/arch/i386/kernel/time-xen.c |   11 +++++++++--
 patches/linux-2.6.16.13/rcu_needs_cpu.patch      |   16 ++++++++++++++++
 2 files changed, 25 insertions(+), 2 deletions(-)

diff -r 34ff26fb2240 -r c230dbe793d6 
linux-2.6-xen-sparse/arch/i386/kernel/time-xen.c
--- a/linux-2.6-xen-sparse/arch/i386/kernel/time-xen.c  Mon Jun 12 12:01:32 
2006 +0100
+++ b/linux-2.6-xen-sparse/arch/i386/kernel/time-xen.c  Mon Jun 12 14:17:05 
2006 +0100
@@ -978,12 +978,19 @@ static void stop_hz_timer(void)
        unsigned int cpu = smp_processor_id();
        unsigned long j;
 
-       /* We must do this /before/ checking rcu_pending(). */
        cpu_set(cpu, nohz_cpu_mask);
+
+       /* See matching smp_mb in rcu_start_batch in rcupdate.c.  These mbs  */
+       /* ensure that if __rcu_pending (nested in rcu_needs_cpu) fetches a  */
+       /* value of rcp->cur that matches rdp->quiescbatch and allows us to  */
+       /* stop the hz timer then the cpumasks created for subsequent values */
+       /* of cur in rcu_start_batch are guaranteed to pick up the updated   */
+       /* nohz_cpu_mask and so will not depend on this cpu.                 */
+
        smp_mb();
 
        /* Leave ourselves in 'tick mode' if rcu or softirq pending. */
-       if (rcu_pending(cpu) || local_softirq_pending()) {
+       if (rcu_needs_cpu(cpu) || local_softirq_pending()) {
                cpu_clear(cpu, nohz_cpu_mask);
                j = jiffies + 1;
        } else {
diff -r 34ff26fb2240 -r c230dbe793d6 patches/linux-2.6.16.13/rcu_needs_cpu.patch
--- /dev/null   Thu Jan 01 00:00:00 1970 +0000
+++ b/patches/linux-2.6.16.13/rcu_needs_cpu.patch       Mon Jun 12 14:17:05 
2006 +0100
@@ -0,0 +1,33 @@
+--- ../pristine-linux-2.6.16.13/kernel/rcupdate.c      2006-05-02 
22:38:44.000000000 +0100
++++ ./kernel/rcupdate.c        2006-06-09 20:27:45.000000000 +0100
+@@ -485,6 +485,20 @@ int rcu_pending(int cpu)
+               __rcu_pending(&rcu_bh_ctrlblk, &per_cpu(rcu_bh_data, cpu));
+ }
+ 
++/*
++ * Check to see if any future RCU-related work will need to be done
++ * by the current CPU, even if none need be done immediately, returning
++ * 1 if so.  This function is part of the RCU implementation; it is -not-
++ * an exported member of the RCU API.
++ */
++int rcu_needs_cpu(int cpu)
++{
++      struct rcu_data *rdp = &per_cpu(rcu_data, cpu);
++      struct rcu_data *rdp_bh = &per_cpu(rcu_bh_data, cpu);
++
++      return (!!rdp->curlist || !!rdp_bh->curlist || rcu_pending(cpu));
++}
++
+ void rcu_check_callbacks(int cpu, int user)
+ {
+       if (user || 
+--- ../pristine-linux-2.6.16.13/include/linux/rcupdate.h       2006-05-02 
22:38:44.000000000 +0100
++++ ./include/linux/rcupdate.h 2006-06-09 20:28:57.000000000 +0100
+@@ -134,6 +134,7 @@ static inline void rcu_bh_qsctr_inc(int 
+ }
+ 
+ extern int rcu_pending(int cpu);
++extern int rcu_needs_cpu(int cpu);
+ 
+ /**
+  * rcu_read_lock - mark the beginning of an RCU read-side critical section.

_______________________________________________
Xen-changelog mailing list
Xen-changelog@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-changelog

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-changelog] [xen-unstable] [LINUX] Fix interaction between idle loop and RCU subsystem., Xen patchbot-unstable <=