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

[Joao Martins <joao.m.martins@xxxxxxxxxx>]

On 08/29/2016 10:41 AM, Jan Beulich wrote:
>>>> 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.

Thanks for the insight.

What would be a preferred period - probably capping it to a day/hour/minutes? Or
keeping the current calculated value? Maximum right now in current platform 
timers
are few minutes depending on the HPET frequency.

Joao

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