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] pv_ops: entry.S simplification

To: "Isaku Yamahata" <yamahata@xxxxxxxxxxxxx>
Subject: RE: [Xen-ia64-devel] pv_ops: entry.S simplification
From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Date: Fri, 28 Mar 2008 16:50:25 +0800
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 28 Mar 2008 02:00:19 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20080328080039.GI3532%yamahata@xxxxxxxxxxxxx>
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>
References: <10EA09EFD8728347A513008B6B0DA77A02EBBFA4@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <1205848595.27908.41.camel@bling> <10EA09EFD8728347A513008B6B0DA77A02EF85FE@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20080327064124.GK29232%yamahata@xxxxxxxxxxxxx> <10EA09EFD8728347A513008B6B0DA77A02F77655@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20080328053424.GD3532%yamahata@xxxxxxxxxxxxx> <10EA09EFD8728347A513008B6B0DA77A02F77A93@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20080328080039.GI3532%yamahata@xxxxxxxxxxxxx>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AciQqntfkiX/a+eGTgurYDyx/UsDwwABYTIQ
Thread-topic: [Xen-ia64-devel] pv_ops: entry.S simplification
Isaku Yamahata wrote:
> On Fri, Mar 28, 2008 at 01:43:23PM +0800, Dong, Eddie wrote:
> 
>>> Eventually those running_on_xen checks should be removed somehow.
>>> Are you just thinking that the multi compile with binary patching
>>> should be introduced after the first merge?
>>> Or do you have any idea other than the multi compile with binary
>>> patching? 
>>> 
>> 
>> Dual compile every change may be not necessary for me.
>> The reason for IVT is that code there is very critical and
>> stakeholders won't change them to steal registers. They even don't
>> want a single change without full hand of performance data + stress
>> test. 
>> 
>> In entry.S, steal clobber register is easy.
> 
> ia64_swtich_to(), ia64_leave_syscall() and ia64_leave_kernel()
> are also performance critical, aren't they?
> 
> 

If we rate those performance critical items, I would vote IVT as 1st,
and
then followed by fast system call. The 3rd one can be this one.

A handler of IVT is in the range of 20-50 instructions, a fast hypercall

may be less than 100 instructions. For ia64_switch_to, the scheduler 
& switch code is in levels of multiple handreds of instructions in my
understanding. 

Putting indirect function call of pv_ops here just introduce 3-10
additional
instructions. Is this what you concern?

Thanks, eddie


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