Re: [Xen-devel] [PATCH v3 3/6] x86/time: streamline platform time init on plt_update()

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 26.08.16 at 17:12, <joao.m.martins@xxxxxxxxxx> wrote:
> On 08/25/2016 11:13 AM, Jan Beulich wrote:
>>>>> On 24.08.16 at 14:43, <joao.m.martins@xxxxxxxxxx> wrote:
>>> And use to initialize platform time solely for clocksource=tsc,
>>> as opposed to initializing platform overflow timer, which would
>>> only fire in ~180 years (on 2.2 Ghz Broadwell processor).
>> 
>> Do we really want to risk this time period going down by two orders
>> of magnitude? Is there anything that's really expensive in setting the
>> overflow timer in the far distant future?
> It wasn't about cost but rather setting the timer in a so distant future. I 
> could
> decrease to an year time, month or day. But do you think we really need that 
> overflow
> handling for TSC?

I think we shouldn't introduce latent issues, no matter how unlikely
we may deem it for them to actually become active ones. Just
consider how unlikely it would have seemed to someone in the
i586 days (when the TSC got introduced) that clock speeds might
ever cross the 4GHz boundary. As a consequence long ago Linux
did use a 32-bit variable for it. It got noticed early enough before
processors got really close to that boundary, but it demonstrates
the fundamental issue. And yes, processor speeds have stopped
to always grow (at least in the x86 space), but that's not a rule
set in stone.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel