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] Time skew on HP DL785 (and possibly other boxes)

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: RE: [Xen-devel] Time skew on HP DL785 (and possibly other boxes)
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Tue, 7 Apr 2009 06:48:04 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "john.v.morris@xxxxxx" <john.v.morris@xxxxxx>, "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 06 Apr 2009 15:49:14 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <5482fb72-856d-4bc8-8f5f-0f4b68a0dc23@default>
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: <0A882F4D99BBF6449D58E61AAFD7EDD61024D386@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <5482fb72-856d-4bc8-8f5f-0f4b68a0dc23@default>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acm2xc9V0YOsOi7zTNW3MTFfMIJPjwAQak8A
Thread-topic: [Xen-devel] Time skew on HP DL785 (and possibly other boxes)
>From: Dan Magenheimer [mailto:dan.magenheimer@xxxxxxxxxx] 
>Sent: 2009年4月6日 22:41
>> Well, my point is a bit out of topic here. Of course your
>> concern about cross-node TSC variance still makes sense
>> whether or not node affinity is enforced, as long as VM is
>> possibly migrated cross-nodes. My point is just that turn
>> on 'numa' itself is really not a 'extremely restrictive'
>> thing. :-)
>Hi Kevin --
>I think numa-mode is extremely restrictive because
>it makes a 32-way box work like eight 4-way blades.

virtualization in itself is something partitioned with each VM
representing one working set. Most VMs deployed so far
haven't requirement over virtual 4-way blades, and thus above
restriction is less relaxed. Then it's natural to span them
in-nodes instead of cross-nodes.

>I think the whole point of HT/QPI is to reduce the
>memory latency enough so that a NUMA box does not
>look like a NUMA box.  If time synchronization fails
>so that this type of box is forced to be partitioned,
>the value of HT/QPI is greatly diminished (at least
>in a virtualization environment).

It's orthogonal. The effort to keep reducing memory latency
on NUMA box doesn't mean no observable memory latency
difference for local and remote memory.

Xen-devel mailing list