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-3.0-testing] [LINUX] Fix interaction between idle l

To: xen-changelog@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-changelog] [xen-3.0-testing] [LINUX] Fix interaction between idle loop and RCU subsystem.
From: Xen patchbot-3.0-testing <patchbot-3.0-testing@xxxxxxxxxxxxxxxxxxx>
Date: Mon, 12 Jun 2006 17:15:40 +0000
Delivery-date: Mon, 12 Jun 2006 10:17:27 -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 15089a58a425cfd556f485d37fd2874e59b3e6bf
# Parent  669a737174af5e82d589a584e6f4f904a09aa09c
[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>
xen-unstable changeset:   10327:c230dbe793d623d67ca1d486c0c1a8db5c7cab94
xen-unstable date:        Mon Jun 12 14:17:05 2006 +0100
---
 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 669a737174af -r 15089a58a425 
linux-2.6-xen-sparse/arch/i386/kernel/time-xen.c
--- a/linux-2.6-xen-sparse/arch/i386/kernel/time-xen.c  Sun Jun 11 20:34:23 
2006 +0100
+++ b/linux-2.6-xen-sparse/arch/i386/kernel/time-xen.c  Mon Jun 12 14:18:52 
2006 +0100
@@ -978,12 +978,19 @@ 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 669a737174af -r 15089a58a425 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:18:52 
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-3.0-testing] [LINUX] Fix interaction between idle loop and RCU subsystem., Xen patchbot-3 . 0-testing <=