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

RE: [Xen-ia64-devel] pv_ops: entry.S simplification


  • To: "Isaku Yamahata" <yamahata@xxxxxxxxxxxxx>
  • 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
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • 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


 


Rackspace

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