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] RE: rid virtualization

To: "Dong, Eddie" <eddie.dong@xxxxxxxxx>, "Matt Chapman" <matthewc@xxxxxxxxxxxxxxx>
Subject: RE: [Xen-ia64-devel] RE: rid virtualization
From: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Date: Tue, 22 Nov 2005 16:24:01 -0800
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 23 Nov 2005 00:23:46 +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-index: AcWymv+kaWWtdUwnRXGUQLAgunG8QQ6STh2wAA4IsAAAqO7lIAAAkR/A
Thread-topic: [Xen-ia64-devel] RE: rid virtualization
>       It is still too early for Xen/IA64 to do performance 
> mesurement now as there are so many stability issues so far.

Perhaps you are right.  I expect that it would take a big
database application to show any difference between the
two algorithms.

> As Matt has a lot of experience in LVHPT hash algorithm 
> (Linux LVHPT previous maintainer) and we agree his analysis 
> is correct, right? 

OK.  But then let's do it right by reversing all the bits
so that we don't have to change it yet again in the future.

See:
http://lists.xensource.com/archives/html/xen-ia64-devel/2005-09/msg00102.html

>       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

I think there is only one place where mangling is done in
assembly (hyper_set_rr), but I could be wrong.  In any
case, I agree that the definitions should be in one place.

We could put an assembly macro in region_reg.h (using
ifdef __ASSEMBLER__ around the macro and ifndef __ASSEMBLER__
around all C code.

Dan
 
> -----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
<Prev in Thread] Current Thread [Next in Thread>