| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] RE: Host Numa informtion in dom0
|
To: |
"Nakajima, Jun" <jun.nakajima@xxxxxxxxx>, Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, "Kamble, Nitin A" <nitin.a.kamble@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Andre Przywara <andre.przywara@xxxxxxx> |
|
Subject: |
RE: [Xen-devel] RE: Host Numa informtion in dom0 |
|
From: |
Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> |
|
Date: |
Tue, 9 Feb 2010 19:25:49 -0800 (PST) |
|
Cc: |
|
|
Delivery-date: |
Tue, 09 Feb 2010 19:28:10 -0800 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<54B2EB610B7F1340BB6A0D4CA04A4F1012BABA32@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> |
|
References: |
<8EA2C2C4116BF44AB370468FBF85A7770123904A29@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4FA716B1526C7C4DB0375C6DADBC4EA342D83D9EBC@xxxxxxxxxxxxxxxxxxxxxxxxx> <06d2c17f-cf69-4ef6-ab29-163bb3038bdb@default 54B2EB610B7F1340BB6A0D4CA04A4F1012BABA32@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
While I am in agreement in general, my point is that we
need to avoid misleading virtualization users by somehow
making it clear that "pinning NUMA memory" to get
performance advantages results in significant losses
in flexibility. For example, it won't be intuitive
to users/admins that starting guest A and then starting
guest B may result in very different performance
profile for A's applications than starting guest B
and then starting guest A.
This may be obvious for other flexibility limiters such
as PCI passthrough, but I suspect the vast majority of
users (at least outside of the HPC community) for the next
few years are not going to accept that one chunk of memory
is *that* different from another chunk of memory.
> -----Original Message-----
> From: Nakajima, Jun [mailto:jun.nakajima@xxxxxxxxx]
> Sent: Tuesday, February 09, 2010 3:03 PM
> To: Dan Magenheimer; Ian Pratt; Kamble, Nitin A; xen-
> devel@xxxxxxxxxxxxxxxxxxx; Andre Przywara
> Subject: RE: [Xen-devel] RE: Host Numa informtion in dom0
>
> Dan Magenheimer wrote on Fri, 5 Feb 2010 at 12:33:19:
>
> > It would be good if the discussion includes how guest NUMA
> > works with (or is exclusive of) migration/save/restore. Also,
> > the discussion should include the interaction (or exclusivity
> > from) the various Xen RAM utilization technologies -- tmem,
> > page sharing/swapping, and PoD. Obviously it would be great
> > if Xen could provide both optimal affinity/performance and optimal
> > flexibility and resource utilization, but I suspect that will
> > be a VERY difficult combination.
> >
>
> I think migration/save/restore should be excluded at this point, to
> keep the design/implementation simple; it's a performance/scalability
> feature.
>
> Jun
> ___
> Intel Open Source Technology Center
>
>
>
<<attachment: winmail.dat>> _______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home