[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Xen-ia64-devel] RE: Timer merge
> >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.
Xen-ia64-devel mailing list