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

Re: [Xen-devel] Re: [PATCH] Fixed legacy issues when extends number of v

To: "Li, Xin" <xin.li@xxxxxxxxx>, "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH] Fixed legacy issues when extends number of vcpus > 32
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Mon, 17 Aug 2009 07:50:00 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sun, 16 Aug 2009 23:50:34 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <E88DD564E9DC5446A76B2B47C3BCCA150215F8F3DA@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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcoeF6u/T7x3fDZwRTGhuLTahDvILQAL2GrBAAHwiDAAAjqxHAAoiqngAANC6V8=
Thread-topic: [Xen-devel] Re: [PATCH] Fixed legacy issues when extends number of vcpus > 32
User-agent: Microsoft-Entourage/12.20.0.090605
On 17/08/2009 07:40, "Li, Xin" <xin.li@xxxxxxxxx> wrote:

> I'd agree that as VPID space is per LP, it's not necessary to be globally
> managed.
> If we manage such a big VPID space using a bitmap on each LP, it will require
> quite
> a few memory and be inefficient on VPID allocation and reclaim. So probably we
> can apply the current ASID allocation approach to VPID assuming VPID
> exhaustion
> will be much less.
> 
> On the other side, I can't understand why we need to consider the overflow of
> generations?

Well, the guy who developed it wanted to consider that case. But it is
pretty pointless of course since a 64-bit generation counter will never
overflow.

Anyhow, your current patch is clearly an improvement on the existing VPID
code, so we'll go with that for the time being.

 Thanks,
 Keir



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