[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 0/2] range timer support
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. 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? > 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |