On Tue, 2009-02-10 at 22:42 +0800, Wei, Gang wrote:
> On Tuesday, February 10, 2009 2:44 AM, Gary Grebus wrote:
> > On Mon, 2009-02-09 at 14:26 +0800, Wei, Gang wrote:
> > ...
> >> Is there any objections, comments or concerns for such a enhancement?
> >>
> >> BTW, current vpt code try to handle vLAPIC specially to give vLAPIC ticks a
> >> offset from other timer ticks like below: pt->scheduled = NOW() +
> >> delta;
> >> /*
> >> * Offset LAPIC ticks from other timer ticks. Otherwise guests which
> >> use
> >> * LAPIC ticks for process accounting can see long sequences of process
> >> * ticks incorrectly accounted to interrupt processing. */
> >> if ( pt->source == PTSRC_lapic )
> >> pt->scheduled += delta >> 1;
> >>
> >> But I don't think this way can really reach the offset purpose, because the
> >> additional (delta >> 1) can't prevent other timers created in other time to
> >> expires right before lapic ticks.
> >>
> >> Will it really bring issues if vlapic ticks and vhpet ticks were aligned?
> >
> > In that case, it was the 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. Skewing the vlapic
> > was sufficient to fix the problem. This only showed up with old Linux
> > kernels (IIRC, it was with Red Hat 3 U8).
> >
> > If the effect of your proposed change is to always deliver all timer
> > interrupts to the guest in immediate succession, then I think you will
> > cause a regression on this problem.
>
> Thanks for the reply. First, we have the same concern. But it's only for
> specific purpose (accounting) in specific old guest. For most other guests I
> am afraid this offset can't really resist vpit or other vpts being delivered
> with vlapic in immediate succession if guest initialize PIT or other platform
> timer a bit far away from LAPIC init. Anyway, we could mention it as the
> alerts for this feature when people'd like to save power. BTW, the range
> timer has similar effect which could nullify the offset effect too.
>
But the customer using that accounting data won't be happy, even if they
are saving a couple watts. Especially since the data is likely to be
only intermittently wrong. It sounds like, for correctness, there
should be more done to avoid having the virtual timers tick in immediate
succession, not less as you propose.
I suppose if there is a configuration parameter, we can deal with it by
adding one more guest-specific configuration rule.
/gary
> Second, our solution does not intend to remove this offset. We just tries to
> provide a power-saving feature via a configurable way. For such feature some
> side effect may exist but the overall gain is more power efficient. I will
> make my patch ready soon, and we can do further discussion on the
> implementation level then.
>
> Jimmy
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home