[Xen-ia64-devel] RE: Timer merge

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

> >Delivering all ticks to all guests is certainly not
> >scalable.  Say there are 1000 lightly-loaded guests sharing
> >a single processor server.  The entire processor would be
> >utilized just delivering all the ticks to each guest!
> >
> >Is this what Xen/x86 does?
> 
> Eddie explained the difference in last mail. Since you also 
> agree there's no need to inject all ticks into all guest, 
> this factor somehow reduces the necessity to always inject 
> virtual timer interrupt that quick in fast path. (Yes, a 
> clean fast path is always welcomed. ;-)

I'm not sure I agree.  Although there is no need to inject
all the ticks when a guest "wakes up", there is still a need
to inject all the ticks when a guest is active, and this
is still 1024 hz for Linux.

> >> Now HZ is defined as 100 in config.h, however current itm
> >> modification policy actually makes this periodic value
> >> useless. Even when itm_delta is added and set into itm, an
> >> immediately following ac_timer softirq will reprogram the itm
> >> to the closest time point in the ac timer list.
> >
> >This sounds like a bug (but on the path for scheduling domains,
> >not delivering guest ticks, correct?)
> 
> This is a bug if you want to keep a periodic HZ concept in 
> hypervisor. (Maybe we can abandon it and only keep a one-shot 
> timer model later). It's unrelated to this discussion, and 
> just raised it since mentioned in the context.

I'm not sure I understand the differences between the periodic
HZ concept and the one-shot timer model... doesn't there always
need to be a timeout for the currently running domain so
the hypervisor scheduler can schedule a different domain?

> IMO, the extra work should at least keep a global monotonic 
> increasing variable to hold itc value at last time interrupt. 
> Then the delta value of guest itc should base on this global 
> variable, instead of local itc. When emulating read_from_itc, 
> we may return by formula like "(now_itc > monotonic_itc) ? 
> (now_itc + vitc_delta) : (monotonic_itc + vitc_delta)". This 
> can promise itc never going backward when vcpu migration. En, 
> anyway this is just some rough thought immediately raised, 
> and we definitely need elaborate and detail discussion in 
> design for vcpu migration. Currently we just need a guest ITM 
> together with ITC delta, as Eddie suggested.

So in your model, reading itc is privileged?  (e.g. secure
itc bit is on)  In the current model, it is not.

> Since SGI guys are also doing something on XEN/IPF, I'm 
> afraid that we'll see possible issue on SN ia64 platform 
> soon. IFIRC, SN platform has un-synchronized ITC, and thus 
> requires a platform RTC timer source to adjust system time. 
> Also SN box has been supported well on current linux release. 
> Maybe some SGI people can jump out to give expertise idea here. ;-) 

Greg, are you still listening out there?
 
> I agree we should enhance current code step by step without 
> anything regressed, (even linux timer source has been 
> modified so many times). We can keep such parallel discussion 
> to learn more ideas from community, at same time with 
> agreement to merge current time code with minimal impact in 
> first step.

Sounds good!

Dan

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