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-devel

[SPAM] Re: [Xen-devel] A patch to xen/arch/x86/hvm/pmtimer.c for both Xe

To: "Song Xiang" <classicxsong@xxxxxxxxx>
Subject: [SPAM] Re: [Xen-devel] A patch to xen/arch/x86/hvm/pmtimer.c for both Xen 4.0.0 and Xen 4.0.1 to improve HVM scalability
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Tue, 16 Nov 2010 07:50:11 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Haibo Chen <oldseawave@xxxxxxxxx>
Delivery-date: Mon, 15 Nov 2010 23:51:01 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <22C8C9FD-3B4A-45C2-A901-15A25648482A@xxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1208B612-80C6-4009-ACEB-1D4E99D0FA7E@xxxxxxxxx> <4CE0FD5102000078000222D9@xxxxxxxxxxxxxxxxxx> <22C8C9FD-3B4A-45C2-A901-15A25648482A@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On 16.11.10 at 15:51, Song Xiang <classicxsong@xxxxxxxxx> wrote:
> We updated our patch as follows:
> 
> Index: arch/x86/hvm/pmtimer.c
> ===================================================================
> --- arch/x86/hvm/pmtimer.c
> +++ arch/x86/hvm/pmtimer.c
> @@ -206,13 +206,23 @@
> 
>       if ( dir == IOREQ_READ )
>       {
> -        spin_lock(&s->lock);
> -        pmt_update_time(s);
> -        *val = s->pm.tmr_val;
> -        spin_unlock(&s->lock);
> +        uint32_t tmp;
> +        /*
> +         * if acquired the PMTState lock then update the time
> +         * else other vcpu is updating it ,it should be up to date.
> +         */
> +        tmp = atomic_read(&s-> ownership);
> +        if (spin_trylock(&s->lock)) {
> +            pmt_update_time(s);
> +            *val = s->pm.tmr_val;
> +            spin_unlock(&s->lock);
> +            atomic_inc(&s-> ownership);
> +        }
> +        else {
> +            while (tmp == atomic_read(&s-> ownership));
> +
> +           *val = s->pm.tmr_val;
> +        }
>           return X86EMUL_OKAY;
>       }
> 
> Index: include/asm-x86/hvm/vpt.h
> ===================================================================
> --- include/asm-x86/hvm/vpt.h
> +++ include/asm-x86/hvm/vpt.h
> @@ -120,6 +120,7 @@
>       uint64_t scale;             /* Multiplier to get from tsc to  
> timer ticks */
>       struct timer timer;         /* To make sure we send SCIs */
>       spinlock_t lock;
> +   atomic_t ownership;
>   } PMTState;
> 
>   struct pl_time {    /* platform time */
> 
> 
> The key idea is, to keep the returned time fresh, any VCPU that fails  
> to acquire the PMTState lock will wait until the PMTState lock holder  
> updates the global virtual time, and then returns the freshest time.
>
> We add a field in PMTState, named ownership. The PMTState->ownership  
> can only be updated by the PMTState lock holder.It is updated after  
> the PMTState lock holder has updated the global virtual time and  
> released the MTState lock.  Other VCPUs that fail to acquire the  
> PMTState lock will check whether the MTState->ownership is updated in  
> a while loop.  When the PMTState->ownership is changed, the global  
> virtual time must be the freshest, and can be returned to the guest OS.
> 
> The time returned to the guest in this patch is fresher than the  
> previous one we have proposed.

That's not better: Depending on timing, the reader may well loop
until the *next* acquirer releases the lock (and increments
"ownership").

Jan


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