[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-ia64-devel] RE: rid virtualization


  • To: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
  • 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
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • Thread-index: AcWvMTOFrA1NTBYWSFqi8GJ1sqb6yAACBR0wABR/zTAAEUNDQA==
  • 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?

Dan

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.