All of lore.kernel.org
 help / color / mirror / Atom feed
From: David F Barrera <dfbp@us.ibm.com>
To: Harry Butterworth <harry@hebutterworth.freeserve.co.uk>
Cc: xen-devel@lists.xensource.com
Subject: Re: [PATCH] UNTESTED backport rcu_needs_cpu and call it from	stop_hz_timer UNTESTED
Date: Fri, 09 Jun 2006 18:45:31 -0500	[thread overview]
Message-ID: <448A081B.5070509@us.ibm.com> (raw)
In-Reply-To: <1149884488.9498.11.camel@localhost.localdomain>

Harry Butterworth wrote:
> THIS PATCH FOR REVIEW ONLY IT'S UNTESTED!!!!!!  Ill test on Monday if
> no-one has done it by then.
>
> 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@uk.ibm.com>
>
>   
> ------------------------------------------------------------------------
>
> diff -r 8c64169a05d3 -r 8ef455f268b3 linux-2.6-xen-sparse/arch/i386/kernel/time-xen.c
> --- a/linux-2.6-xen-sparse/arch/i386/kernel/time-xen.c	Thu Jun  8 08:52:04 2006
> +++ b/linux-2.6-xen-sparse/arch/i386/kernel/time-xen.c	Fri Jun  9 19:47:18 2006
> @@ -978,12 +978,19 @@
>  	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 8c64169a05d3 -r 8ef455f268b3 patches/linux-2.6.16.13/rcu_needs_cpu.patch
> --- /dev/null	Thu Jun  8 08:52:04 2006
> +++ b/patches/linux-2.6.16.13/rcu_needs_cpu.patch	Fri Jun  9 19:47:18 2006
> @@ -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-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>   
Harry,

I am doing some quick testing of your patch. So far, the results are 
consistent with the mainline testing results.

-- 

Regards,

David F Barrera
Linux Technology Center
Systems and Technology Group, IBM

"The wisest men follow their own direction. "
	
                          Euripides

  reply	other threads:[~2006-06-09 23:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-09 20:21 [PATCH] UNTESTED backport rcu_needs_cpu and call it from stop_hz_timer UNTESTED Harry Butterworth
2006-06-09 23:45 ` David F Barrera [this message]
2006-06-12 11:57 ` [PATCH] backport rcu_needs_cpu and call it from stop_hz_timer Harry Butterworth
2006-06-12 12:47   ` Keir Fraser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=448A081B.5070509@us.ibm.com \
    --to=dfbp@us.ibm.com \
    --cc=harry@hebutterworth.freeserve.co.uk \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.