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-ia64-devel] RE: Xen/ia64 - global or per VP VHPT

To: "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>, "Yang, Fred" <fred.yang@xxxxxxxxx>
Subject: [Xen-ia64-devel] RE: Xen/ia64 - global or per VP VHPT
From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Date: Sun, 1 May 2005 20:05:41 +0800
Cc: ipf-xen <ipf-xen@xxxxxxxxx>, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Sun, 01 May 2005 12:05:32 +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: AcVKfesR741jQGkzQvWmdNAbNvskDgAAPPdQAAnH97AAJJJm8AAGJlmgACr730AABzFgcAAYTImwABTis7AAALccgAAAPutgABLQl4AAN60BYAARFB9A
Thread-topic: Xen/ia64 - global or per VP VHPT
Magenheimer, Dan (HP Labs Fort Collins) wrote:
> 
> Um, no, it has critical problems/limitations for VT domains.
> I don't see the same problems with non-VT.  But since we
> don't want to have different hypercall APIs for VT and non-VT,
> I agree that hypercall parameters should be passed in memory.
> 
> I don't think this applies to "global VHPT vs per-domain VHPT"
> as this should be completely invisible to guestOS.  And I
> think it should be possible (fairly easy) to support both:
> per-domain for VT domains and global for non-VT.
How can you guarantee the MAP for hypercall will not be purged without
extra data structure I mean vTLB?  
> 
> 
> These are good questions for a VT domain.  Its not clear if/how
> they apply for non-VT.
> 
> I'm not arguing that VT domains should use a global VHPT,
> I'm arguing that non-VT domains can.   It may prove that
> per-domain works better for non-VT too, but I want to
> preserve the option to explore that.
Before I saw your whole proposal to support an never automatically
purgeable entry for hypercall shared page. I saw big effort to support
this in global VHPT solution.
> 
Actually vMMU is not only VHPT issues. Another important thing is vTLB.
The current implementation doesn't include any vTLB code. If we decide
to develop hypercalls base on my vMMU implementation, the extra effort
is quit small (just several hours to enable), but I am afraid it is quit
difficult to support on current global VHPT implementation.

> OK, let me try again.  Let's assume a system has 64GB and (by whatever
> means) we determine that a 1GB VHPT is the ideal size for a 64GB
> system.  Now let's assume an environment where the "load" (as measured
> by number of active guests competing for a processor) is widely
> variable... say maybe a national lab where one or two hardy
> allnighters run their domains during the night but 16 or more run
> during the day. Assume also that all those domains are running apps
> that are heavily memory intensive, that is they will use whatever
> memory is made available but can operate as necessary with less
> memory.  So 
> when the one domain is running, it balloons up to a full 64GB
> but when many are running, they chug along with 4GB or less each.
> 
> The global VHPT allocates 1GB at Xen boot time.
> 
> How big a VHPT do you allocate for each of the 16 domains?  Surely
> not
> Or are you ballooning the VHPT size along with memory size?
        This is not a big cake. If the domain get more memories(exceed
some threshold), it is ok to increase VHPT size dynamically.
Eddie

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