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/
Home Products Support Community News


[Xen-ia64-devel] RE: rid virtualization

To: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Subject: [Xen-ia64-devel] RE: rid virtualization
From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Date: Fri, 2 Sep 2005 08:16:57 -0700
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 02 Sep 2005 15:14:43 +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-topic: rid virtualization
>       During early this year, I remembered we ever talked about VHPT
> locality issues. The conclusion is that if the rid is 
> randomly allocated
> the VHPT entry will be fairly evenly distributed. After that I noticed
> that you added vmMangleRID() to try to make the rid as random as
> possible. The VTI code has similar code too at that time to switch rid
> bits.
>       I also did a measurement at that time (in VTI environment
> excluding metaphysical map entries) and find a disappoint result that
> almost 70-80% of VHPT entries are invalid while the left 20-30% hot
> entries has long collision chains (Some even has 30+ entries in chain
> vs. average 1). That reminds me to think of RID 
> virtualization to solve
> this problem thoroughly and now I am planning to do that covering both
> global VHPT and per VP VHPT although it is still in design phase.
>       What is your suggestion on that? Or is there anybody else
> already thought of this?

Hi Eddie --

First question: Will the VHPT distribution problem still exist when
we are running multiple domains?

Second question: Can the problem be fixed by improving the "mangling"
code?  (I picked up this code from vBlades, but never really did
a thorough analysis that it provided a good distribution.)

Third question: If we go to a new "random rid distribution" model,
can this be designed with very little memory usage and ensure
that "garbage collection" is efficient when domains migrate very
dynamically?  I'd be concerned if, for example, we kept a 2^24 map
of what domain owns what rid.

I'd be eager to fix this problem as it may be contributing to
the (small but still larger than I expected) slowdown running
on top of Xen.

Also, I'm fairly sure that the code to walk the collision
chains in assembly has never been enabled?


Xen-ia64-devel mailing list

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