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

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

To: "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>, "Matt Chapman" <matthewc@xxxxxxxxxxxxxxx>
Subject: RE: [Xen-ia64-devel] RE: Xen/ia64 - global or per VP VHPT
From: "Munoz, Alberto J" <alberto.j.munoz@xxxxxxxxx>
Date: Sun, 1 May 2005 01:35:58 -0700
Cc: ipf-xen <ipf-xen@xxxxxxxxx>, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sun, 01 May 2005 08:35:57 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: DIscussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcVN9HcbYQ1HKMBkRBqJDi+jgRjOMAAESyzwAAhe5OA=
Thread-topic: [Xen-ia64-devel] RE: Xen/ia64 - global or per VP VHPT
Hi Dan,

Magenheimer, Dan (HP Labs Fort Collins) <mailto:dan.magenheimer@xxxxxx>
wrote on Saturday, April 30, 2005 9:38 PM:

>> When implementing the lVHPT in Linux I decided on a per-CPU
>> VHPT for the
>> scalability reasons that you cite.  And one drawback is, as Dan says,
>> that it may be difficult to find a large enough chunk of free physical
>> memory to bring up a new processor (or domain in the per-domain case).
> 
> Thanks for chiming in Matt!
> 
> Wow, I hadn't even realized before you mentioned it... a lVHPT is
> generally contiguous in physical memory because it has to be
> pinned by a TR (or more than one TR, but there's not many to choose
> from!).

No, the VHPT does not have to be pinned by a TR. People do it, but it does
not have to be that way. 

In any case, I don't think the number of TRs is a problem. In the global
VHPT case you have the same TR mapping in all processors (you use one TR).
In the per domain VHPT case you could use the same one TR, only that it has
different contents (per domain) in different processors.

> 
> That may not be a problem when you know in advance how many domains
> are going to run on the machine and you partition the memory in advance,
> but it's a HUGE disadvantage for per-domain VHPT in the highly dynamic
> environment we envision at HP, with domains being frequently created,
> growing, shrinking, and migrating.  E.g. creating a domain may require
> a massive defrag operation to just allocate the per-domain VHPT.
> And growing/shrinking a per-domain VT dynamically is MUCH more
> difficult.
> 
> I see that as a HUGE problem for using per-domain VHPTs for VT
> domains too.  Or am I missing something?

Yes, you are missing the following:

- VHPTs do not have to be made up of physically contiguous memory or mapped
by TRs

- If you had a single global VHPT and you wanted to pin it with a TR, then
you could not grow it or shrink it dynamically without running into the
issue you mention about finding physically contiguous memory.

- If you cannot grow or shrink your VHPT, then you need to preallocate it to
its maximum size at boot time regardless of how many domains are running.

- If you are willing to preallocate memory at boot, you could do this for
per domains VHPTs also, by preallocating an area of contiguous memory at
boot that is used for allocating memory for VHPTs.

> 
> This is an excellent example of how assumptions can influence design...

I agree with you, but I have the feeling we are looking at the example from
different angles :-)

> 
> Now back (finally) to my regularly scheduled weekend :-)

Bert

Attachment: smime.p7s
Description: S/MIME cryptographic signature

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