At 17:24 +0100 on 08 Oct (1255022685), Dan Magenheimer wrote:
> Tongue-in-cheek noted. ;-) But seriously, what I'm proposing
> is that now that this is architected by the processor, poorly
> designed systems (or extremely large systems) should be the rare
> exception, not the rule.
That seems like unwarranted optimism, but we'll just have to wait and
see. I've seen enough bugs that boiled down to reputable system
builders doing things that software engineers thought would surely never
happen.
> A) unsafe (neither constant nor power-invariant)
> B) semi-safe (constant = P-,T-state invariant, C-state may stop)
> C) safe (constant+non-stop = P-,T-,and C-state invariant)
> D) false-positive safe (CPUs safe, system-wide is not)
OK; for the record I believe C should be assumed to be D.
> Xen currently assumes A.
That's what I meant by detection and correction.
> This is sufficient for Xen's needs,
> and for the pvclock algorithm, but insufficient for my
> plans to expose "TSC reliability" to usermode.
Your plans for usermode<-->hypervisor direct TSC integration seem to me
to be an unpleasant hack. I understand that you have good business
reasons for wanting it (even if you're not allowed to tell us explicitly
what they are) and we've seen the justifications enough times that we
don't need to cover them again here, but it's still a hack.
I'm unhappy with the idea of kicking around the Xen timekeeping code
(and introducing the usual bug-tail) to support introducing a usermode
TSC. If there is to be a new mode for this, it should default to the
current (works for everyone except the engineering team of a
not-to-be-named enterprise application) behaviour.
> I'm proposing that:
> 1) for case C, Xen shall never overwrite TSC
> 2) for case D, a new "tsc_broken" boot option must be specified
> when Xen is booted on a broken machine
Might as well call it "application_broken" and default it the other
way. :) The system builders are entirely within their rights to have
separate clocks for separate sockets.
Cheers,
Tim.
> 3) for case B, always use it when the hardware supports it
> (unless overridden by "tsc_broken")
>
> We are also investigating whether the write_tsc() in
> the cstate recovery code obviates the need for the
> write_tsc in time_calibration_tsc_rendezvous.
>
> Comments?
>
--
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Citrix Systems (R&D) Ltd.
[Company #02300071, SL9 0DZ, UK.]
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home