RE: [Xen-devel] Re: [PATCH] Align periodic vpts

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> I'm not sure why you count this feature as the cause for guest time
> inaccuracy. This patch only shifts 1st expiration of periodical timer,
> and later expirations are all exactly as expected relative to previous
> one.

OK, if that is correct, I have no problem with the patch.

> VI's issue is not about time inaccuracy or performance, which is
> about accounting.

Many of the problems (and Oracle has seen customers with similar
problems) are related to the timing of delivery of "ticks"
relative to each other, e.g. if consecutive ticks are sometimes
0.01s apart and sometimes 0.0099s apart and sometimes 0.0101s
apart, this causes different problems for different guests with
different default/chosen clocksources.

Dan

> -----Original Message-----
> From: Tian, Kevin [mailto:kevin.tian@xxxxxxxxx]
> Sent: Wednesday, February 11, 2009 8:25 AM
> To: Dan Magenheimer; Keir Fraser; Wei, Gang; xen-devel
> Subject: RE: [Xen-devel] Re: [PATCH] Align periodic vpts
> 
> 
> >From: Dan Magenheimer
> >Sent: Wednesday, February 11, 2009 10:56 PM
> >
> >> > + * CAUTION:
> >> > + * While vlapic timer ticking too close to the pit.  We 
> >> saw a userspace
> >> > + * application getting the wrong answer because long CPU 
> >> bound sequences
> >> > + * appeared to run with zero CPU time. This only showed up 
> >> with old Linux
> >> > + * kernels (IIRC, it was with Red Hat 3 U8). So this 
> >> option may cause a
> >> > + * regression in this case.
> >> > + */
> >> > +static int opt_align_periodic_vpt = 0;
> >> > +boolean_param("align_periodic_vpt", opt_align_periodic_vpt);
> >> > +
> >> 
> >> Presumably there are common cases where not aligning vlapic too has
> >> significant power overheads? Personally I'm not sure I care 
> >> too much about a
> >> minor regression on RH3, if this patch is worthwhile at all 
> >I think it
> >> should be always on and at most have a domain config option. 
> >> I think a boot
> >> option will never ever be used.
> >
> >Given the wide variety of guests, and clocksource defaults/choices
> >in those guests, I'm leery about this change, especially turning it
> >on by default.  The consequences of guest clocks losing time 
> or gaining
> >time or appearing to go backwards are significant and the potential
> >problems go well beyond "a minor regression on RH3" and IMHO are
> >much more impactful for customers than saving a watt or two.
> 
> I'm not sure why you count this feature as the cause for guest time
> inaccuracy. This patch only shifts 1st expiration of periodical timer,
> and later expirations are all exactly as expected relative to previous
> one.
> 
> >
> >It is difficult in a simple test environment to reproduce the
> >problem unless you know what you are looking for.
> >Virtual Iron had a rather extensive set of test cases and I'd
> >like to see those run before this is turned on by default.
> >
> 
> VI's issue is not about time inaccuracy or performance, which is
> about accounting.
> 
> Thanks,
> Kevin

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