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/
Home Products Support Community News


Re: [Xen-devel] [PATCH 3/3] Disable ARB_DIS conditionally

To: "Wei, Gang" <gang.wei@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 3/3] Disable ARB_DIS conditionally
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Wed, 03 Sep 2008 11:40:16 +0100
Delivery-date: Wed, 03 Sep 2008 03:41:12 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <8FED46E8A9CA574792FC7AACAC38FE770180652913@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AckNaBRbmlf20lzgRmapdIQh+qyTZAAOKwDGAAFiUcAAAsqLng==
Thread-topic: [Xen-devel] [PATCH 3/3] Disable ARB_DIS conditionally
User-agent: Microsoft-Entourage/
On 3/9/08 11:21, "Wei, Gang" <gang.wei@xxxxxxxxx> wrote:

> CPU0: -------------judge then clear
> ARB_DIS----------------------------------dec count
> CPU1: inc count-------------------------------------judge then set ARB_DIS

Yes, that's a more likely race.

> Sync via spinlock is good suggest, I need to do some testing to make sure
> spinlock will not bring larger-than-saved overheads.

Actually I think it'll be okay. Place the lock next to the c3_cpu_count (so
they share a cacheline). Something like:

struct {
    spinlock_t lock;
    unsigned int count;
} c3_cpu_status;

 * Currently: Exclusive access to one cache line + one LOCK prefix
 * With lock: Exactly the same (since c3_cpu_count no longer needs to be an
atomic_t, and spin_unlock() is also not a LOCKed instruction).

But yes, you should test just be to be really sure.

 -- Keir

Xen-devel mailing list