Re: [Xen-devel] [PATCH 0/2] range timer support

["Yu Ke" <mr.yuke@xxxxxxxxx>]

2008/10/29 Keir Fraser <keir.fraser@xxxxxxxxxxxxx>:
> On 29/10/08 02:29, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>
>> Yes, this is a valid concern. Simplicity is better if we're not sure
>> the gain by making things complex. I agree that a central slop
>> control is cleaner here. In the meantime how about also adding a flag
>> to disable slop per-timer base? Then timers with stricter delivery
>> requirement can add this flag even when global slop is enabled.
>> Or may be this control can be exposed to user by domctl interface,
>> as a per-domain configurable option.
>
> I actually wonder whether we would get similar to your 5% win by just
> increasing the SLOP parameter to a fixed 1ms. That would equal your
> worst-case slop in the second range-timer patch for vpt timers, and I don't
> really see why any timer in Xen wouldn't be able to deal with that.

Increasing SLOP to 1ms should have the the similar 5% gain, as your
analysis, it is the worst case of range timer application in vpt. I
can redo the measurement to double confirm.

>
> One thing that would be interesting would be some micro-statistics such as
> average C3 residency time, to go along with your macro-statistic of total
> power consumption. Seeing the relationship between the two would let us see
> how much of an effect the residency time has on power consumption and give
> us something more precise to aim for in terms of desirable residency time.
> We could even hack the C3 code in Xen to deliberately set long timeouts, so
> we can measure that relationship more precisely and at extremes. If nothing
> else it might tell us what sort of slop is worthwhile and, if that's small
> enough, perhaps we can just live with it?

That is interesting thing to do. we can measure C3 residency with
different TIME_SLOP value, to see relationship between C3 residency
and TIME_SLOP.

>
>> Actually range timer doesn't hurt performance much as immediately
>> imagined, especially for periodical timers. Normally just 1st
>> alignment may not follow assigned interval, and once they're aligned,
>> later behavior should be similar as before.
>
> I like the range-timer implementation, I'm just not convinced about the
> interface. At the moment, I think I'd rather split the interface into usage
> types (a bit like you suggest above with your domctl idea) -- e.g., this is
> a guest timer, or this is a low-rate periodic timer -- and then hide the
> policy about what is good enough from the consumers of those interfaces.
> Perhaps the range-timer implementation will still be a useful mechanism
> behind such interfaces.
>
>  -- Keir
>

Yes, it is unfair for caller to figure out the range as complex as
"MIN( pt->period/8, MILLISECS(1) )". and it would be convenient if
there is easy-to-use interface, although to be honest, I have no much
idea on how would the interface looks like currently.

here is my two cents just for your reference. I have tried range timer
in several places:
- platform time overflow timer: this timer can be expires anytime
ahead of the deadline, so the range is like [deadline-period/n,
deadline]
- cpufreq ondemand sampling timer: this timer is not so strict to
deadline, both ahead or behind deadline a bit is fine, so the range
can be like [deadline-period/n, deadline+period/n]
- HVM virtual period timer: this timer allow expires behind deadline a
bit, because it has logic to handling missing ticks. so the range can
be [deadline, deadline + period/n]. to be more conservative, it is
safe to add up limit of 1ms. the 1ms comes from the commodity OS
frequency, e.g. Linux kernel has 1000/250/100 HZ, and windows has 64
HZ, 1ms should meet the up limit of 1000HZ.

the user from various sub-system should have more knowledge on their
timer usage model. it would be good if they can provide their
requirement. if enough usage model is got, then probably we can
uniform then and provide easy-to-use API for them.

Best Regards
Ke

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