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] [PATCH] [RESEND] domU destroy & page ref counter

To: "Masaki Kanno" <kanno.masaki@xxxxxxxxxxxxxx>, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx, "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "Xu, Anthony" <anthony.xu@xxxxxxxxx>
Subject: RE: [Xen-ia64-devel] [PATCH] [RESEND] domU destroy & page ref counter
From: Akio Takebe <takebe_akio@xxxxxxxxxxxxxx>
Date: Mon, 13 Mar 2006 18:44:42 +0900
Delivery-date: Mon, 13 Mar 2006 09:47:23 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <571ACEFD467F7749BC50E0A98C17CDD8094E791C@pdsmsx403>
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>
References: <571ACEFD467F7749BC50E0A98C17CDD8094E791C@pdsmsx403>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hi, Kevin and Anthony

Thank you for your comments.

>For refcount:
>- You may want to change PGT_va_shift to 32 like x86-64 since "unsigned 
>long type_info" is 64bit width on IA64. Or you either can define it as "u32 
>type_info" to save space since higher half is not used by your patch.
>
I thought I wanted to be the same struct page as x86.
So I think changing PGT_va_shift to 32 is better 
since "u32 type_info" cannot be saved space.
(because inuse and free are union.)

>For domain destroy:
>- Also need to free metaphysical rid, which is null by far. Current 
>metaphysical rid allocation policy is monotonic-incremental-allocation-no-
>free
> style. Though it's unlikely to see exhaust of this area (one block 
>reserved by
> far), it's better to change it to a cleaner, more efficient policy. You 
>may at 
>least put a call there if delayed with lower priority.
>
As you said, VHPT and TLB flush may be not necessary,
but we use these flush for safe destroy.
So Kan made a feature of allocating rid, then we may be able to remove 
these flush.

Best Regards,

Akio Takebe


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