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

[Xen-devel] RE: Xen/ia64 - global or per VP VHPT

To: "Yang, Fred" <fred.yang@xxxxxxxxx>, "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Subject: [Xen-devel] RE: Xen/ia64 - global or per VP VHPT
From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Date: Fri, 29 Apr 2005 08:29:27 -0700
Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, ipf-xen <ipf-xen@xxxxxxxxx>, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 29 Apr 2005 15:29:10 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcVKfesR741jQGkzQvWmdNAbNvskDgAAPPdQAAnH97AAJJJm8AAGJlmgACr730AABzFgcAAYTImwABTis7A=
Thread-topic: Xen/ia64 - global or per VP VHPT
(Sorry for the cross-posting... I wanted to ensure that
the xen-ia64-devel list members are able to chime in.
With the high traffic on xen-devel, I'm sure many -- like
myself -- fall behind on reading xen-devel!)

> With a single  global VHPT and force the same page size 
> limitation, it means all the Domaons must be paravirtualized 
> to a hard defined pag size; this is definitely to limit the 
> capability of the Xen/ia64.   Will this also imply only 
> certain version of the Domains can run on a same platform?
> What will be the scability issue with a single VHPT table?  
> Imaging multi-VP/Multi-LP, all the LPs walking on the same 
> table, you would need to global purge or send IPI to all 
> processor for purge a single entry.  Costly! 

No, multiple page sizes are supported, though there does have
to be a system-wide minimum page size (e.g. if this were defined
as 16KB, a 4KB-page mapping request from a guestOS would be rejected).
Larger page sizes are represented by multiple entries in the
global VHPT.

Purging is definitely expensive but there may be ways to
minimize that.  That's where the research comes in.

I expect the answer to be that global VHPT will have advantages
for some workloads and the per-domain VHPT will have advantages
for other workloads.  (The classic answer to any performance
question... "it depends..." :-)

> > I agree that purging is a problem, however Linux does not
> > currently change page sizes frequently.
> Again, I hope we are not limiting only one OS version to run 
> on this Xen/ia64.  I believe Linux also needs to purge 
> entries other than page size changes!
> Through per-VP VHPT and VT-I feature of ia64, we can expend 
> Xen/ia64 capability to enable multiple unmodified OS run on 
> Xen/ia64 without knowing what the page size the Domain is using.  

Per-domain VHPT will have its disadvantages too, namely a large
chunk of memory per domain that is not owned by the domain.
Perhaps this is not as much of a problem on VT which will be
limited to 16 domains, but I hope to support more non-VT domains
(at least 64, maybe more).

Is the per-domain VHPT the same size as whatever the domain allocates
for its own VHPT (essentially a shadow)?  Aren't there purge
performance problems with this too?

Dan

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

<Prev in Thread] Current Thread [Next in Thread>