On 10/13/2010 08:56 AM, Dan Magenheimer wrote:
> (bringing the topic up to a more theoretical level and including
> Keir and Jeremy)
>
> I wonder if the "bug" here is that "dependent wall clock" is
> an incredibly poor replacement for NTP (or a Windows Time Server)
> and a hack and really shouldn't even exist? I suppose one could
> argue that it makes some sense in a XCP environment, and maybe
> in a server environment where a single physical server is extremely
> isolated, but does it ever make sense in a real world server
> environment?
>
> In other words, I'm arguing that the correct "fix" here is:
> Don't use dependent wallclock.
Yes, that's always been my view. pvops kernels don't implement it.
J
>> -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx]
>> Sent: Wednesday, October 13, 2010 6:38 AM
>> To: Hang Du
>> Cc: Saipu Liu; Shunli Yi; xen-devel@xxxxxxxxxxxxxxxxxxx
>> Subject: RE: [Xen-devel] [PATCH] time-xen : Reset monotonic time when
>> sync up time from dom0 to domU
>>
>>>>> On 13.10.10 at 05:24, "Du, Hang" <hdu@xxxxxxxxxxxx> wrote:
>>> Sorry for my brief description in previous mail and missing
>>> is_initial_xendomain check. The kernel I submit this patch is
>>> linux-2.6.18-xen-3.4.2, I submit the patch again with in_initial-
>> xendomain
>>> check.
>> Actually, I didn't expect you to blindly insert that check, but rather
>> either explain why only DomU-s need the changed behavior (as your
>> original description suggested), or refine the description of the
>> problem you're trying to solve.
>>
>>> In this patch, we support the backward time changing sync to all
>> domUs which
>>> configured to use "dependent wall clock".
>>> Currently, without the backward time syncing, when we change the time
>>> backward in Dom0, the time in DomU would be froze.
>>> And this cause some commands hang and don't executed until the time
>> catch up
>>> with the domU time.
>>> For example:
>>> "rpm -q kernel-xen"
>>> "sleep 1"
>>> Monotonic time should be reset when sync up time from dom0 to domU to
>>> support domU backward time syncing.
>> I can see your point, however ...
>>
>>> diff -urN a/arch/i386/kernel/time-xen.c b/arch/i386/kernel/time-
>> xen.c
>>> --- a/arch/i386/kernel/time-xen.c 2010-10-11 10:41:06.000000000
>> +0800
>>> +++ b/arch/i386/kernel/time-xen.c 2010-10-11 10:43:32.000000000
>> +0800
>>> @@ -715,6 +715,8 @@
>>> }
>>>
>>> if (shadow_tv_version != HYPERVISOR_shared_info->wc_version) {
>>> + if (!is_initial_xendomain() && !independent_wallclock)
>>> + monotonic_reset();
>>> update_wallclock();
>> ... you definitely need to call monotonic_reset() *after* the
>> update_wallclock() (or else another vCPU, preempted in
>> do_gettimeofday() between the end of the xtime read loop
>> and the acquiring of the monotonic lock, would be able to
>> overwrite monotonic.tv with values obtained before the wall
>> clock update - similar to the secondary problem addressed by
>> c/s 1021).
>>
>> Further, blindly running a reset here doesn't seem nice in
>> the (general) case of the time getting updated forwards.
>>
>>> schedule_clock_was_set_work = 1;
>>> }
>> You'll also want to address Dan's concerns, and you will want to
>> get your patch formatted so that it would actually apply (read:
>> no tab -> space conversion) if you expect it to be committed
>> by Keir at some point.
>>
>> Jan
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home