RE: [Xen-ia64-devel] RE: rid virtualization

["Dong, Eddie" <eddie.dong@xxxxxxxxx>]

Dan:
        It is still too early for Xen/IA64 to do performance mesurement now as 
there are so many stability issues so far. As Matt has a lot of experience in 
LVHPT hash algorithm (Linux LVHPT previous maintainer) and we agree his 
analysis is correct, right? 
        Then back to the coding style for mangling, I suggest we should keep 
one place to do all the mangling like the C code did now, but for all those 
FAST_*, shoud we change that to a unique MACRO or a command function? 
Eddie

-----Original Message-----
From: Magenheimer, Dan (HP Labs Fort Collins) [mailto:dan.magenheimer@xxxxxx] 
Sent: 2005年11月19日 23:24
To: Dong, Eddie; Matt Chapman
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Xen-ia64-devel] RE: rid virtualization

> > I think it would be worth changing the Xen mangling so that it
> > switches bytes 1 and 2 instead of 1 and 3, and seeing if that makes
> > an improvement.
> > 
> > Matt
> 
> Dan:
>       I noticed the latest code is still mangling byte 1 with  bytes 3
> so far. Don't you want to switch to byte 1 and byte 2 mangling that is
> obvious better than current one?
> Thx,eddie

Do you have any benchmark results comparing the two (preferably
with all the FAST_* options turned on in hyperprivop.S)?  Also,
Matt observed that reversing all the bits should be even better.
It would be good to benchmark that too.

If you are looking at this code, please also look to see if
you find any places where rid mangling should be occuring
but is not (e.g. metaphysical mode).  I think I saw a place
where this might be a bug when I was working on fixing another
bug, but don't recall where it was.

Thanks,
Dan

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