linux-kernel - Re: Fwd: [GIT PULL] timer changes for v3.10

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.02.1305081626110.2863@ionos>
Date:	Wed, 8 May 2013 16:34:27 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Pavel Machek <pavel@....cz>
cc:	Ingo Molnar <mingo@...nel.org>,
	John Stultz <john.stultz@...aro.org>,
	Feng Tang <feng.tang@...el.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Fwd: [GIT PULL] timer changes for v3.10

Pavel,

On Wed, 8 May 2013, Pavel Machek wrote:
> > > > Sorry. You seem to not like the merged change, but I guess I'm not
> > > > quite sure what exactly your objection is here.
> > > 
> > > I'm not exactly sure what my objections are.
> > > 
> > > TSC was not designed for long-term precise timekeeping. [...]
> > 
> > The TSC is just a 64-bit counter that can be read very cheaply.
> > 
> > If the TSC is _implemented_ precisely in hardware and is kept in sync over 
> > CPUs then it's obviously fit for long-term precise timekeeping from that 
> > point on.
> 
> Yes. But the clock for TSC is not being generated in CPU (right?) and
> AFAICT, the code said "if the CPU is new enough, assume TSC is good
> timesource". You need good clock for good timesource.

TSC is a good clock source if:

    - Frequency constant (>= Core2)
    - Not affected by C-States (>= Nehalem)
    - Running during Suspend (>= Haswell)

So we only use TSC across Suspend for Haswell and newer. On older
systems we use RTC during suspend, but we still use the TSC as a
clocksource during normal operation.

> > > [...] but some people suspend their machines for longer than that. Plus 
> > > I wonder how it will interfere with /etc/adjtime.
> > 
> > If it's precise then why should it interfere?
> > 
> > The history of the TSC being problematic can be ignored the moment CPU 
> > makers fix it completely - and apparently that is happening...
> 
> AFAICT we normally use RTC/PIT during runtime. If we switch to TSC

No, we do NOT use RTC/PIT during runtime. That's the worst choice one
could make. If TSC is non frequency constant or affected by C-States
we use HPET or PM-Timer, and we only ever use the PIT if nothing else
is available.

RTC is not used at all for timekeeping. RTC is only used at system
start and when we resume and the TSC stopped during that time, which
is true for hibernation even on Haswell and newer.

> during suspend, surely /etc/adjtime will be confused. (RTC has its own
> timesource, so it is unlikely to have same error as TSC).

Nothing gets confused. It's all handled proper in the core code and
the clock source drivers.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/