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: <20130508194923.GA30896@amd.pavel.ucw.cz>
Date:	Wed, 8 May 2013 21:49:23 +0200
From:	Pavel Machek <pavel@....cz>
To:	Thomas Gleixner <tglx@...utronix.de>
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

Hi!

> > > > [...] 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.

Ok, that was part I was missing.

> > 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.

Ok, so this patch means that we will use
TSC(runtime)+TSC(s2ram). That's improvement over
TSC(runtime)+RTC(s2ram). 

[I still wonder how adjtime is going to work in
TSC(runtime)+RTC(s2disk) case; surely TSC has different drift than
RTC, and so adjtime will have fun trying to estimate the drift... but
that's not new problem and not affected by that patch.]

Ok, thanks for explanation, and sorry it took me so long.

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/