[Xen-ia64-devel] RE: Timer merge

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

Since this is a broader architectural discussion, I hope its OK to
promote it to xen-ia64-devel...

Because Linux/ia64 specifies HZ=1024, all the operations associated
with handling a guest clock tick, both in the hypervisor and in
the guest, happen more than 1000 times/second.  This means
they all need to be fast.

The current (non-VTI) code is not perfect but it *is* fast.  This
is due a great deal to the fact that all the operations are
handled either with "fast reflection" or "fast hyperprivop"
code.  This code reflects/emulates operations without requiring
all the state save/restore and stack switching that is necessary
to call C.  Indeed it is done without even turning on psr.ic
because all data that is accessed is pinned by TRs.  As a
result each operation takes on the order of 100 cycles, as
opposed to 1000-2000 cycles if C must be called.  And there are
several (8-10 IIRC) operations per guest timer tick.

The core Xen code for handling timers is all in C so using
any of it will slow every guest timer tick substantially,
thus slowing the entire guest substantially.  It may be
possible to write the semantic equivalent of the Xen ac_timer
code in ia64 assembly, but this defeats the purpose of sharing
the core Xen code.  Also, I'm doubtful that walking timer
queues can be done with psr.ic off.

Note that hypervisor ticks (primarily used for scheduling
timeouts) are much less frequent (32 hz?) so not as
performance-sensitive.  The current code does call C for
these ticks.

In short, I am open to rearchitecting the timer code to
better merge with VTI.  However the changes should not have
a significant effect on performance.  And anything that calls
C code multiple times at 1024hz almost certainly will.

Dan

> -----Original Message-----
> From: Dong, Eddie [mailto:eddie.dong@xxxxxxxxx] 
> Sent: Tuesday, August 23, 2005 9:07 PM
> To: Magenheimer, Dan (HP Labs Fort Collins)
> Cc: Yang, Fred; Tian, Kevin; Xu, Anthony; Mallick, Asit K; Dong, Eddie
> Subject: Timer merge
> 
> Dan:
>       We are looking for simplest way to merge the timer code 
> together now. Probably you still remember the discussion 
> several months ago, now it looks like we are much easier to 
> merge together as the XEN ac_timer is moved to one-shot timer.
> 
> 
>       Current code is setting machine ITM to smallest one of 
> HV timer (HZ=1024), guest ITM (suppose 1024HZ) and next 
> ac_timer. How about following changes to support both VTI & non-VTI?
>       1:  machine ITM is set only by next ac_timer (current 
> non VTI HV also do this)
>       2: Setting guest ITM will be done by adding a new 
> ac_timer for that ITM. (expire = requested_iTM - current ITC)
>       3: HV timer probably is not necessary now, but up to you.
>       4: xen_timer_interrupt do corresponsive modification to 
> reflect above changes.
> 
> 
>       Any suggestion?
> Thx,eddie
>       
> 

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