linux-kernel - Re: [PATCH] Fix TSC calibration issues

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.1.10.0809031817430.3515@nehalem.linux-foundation.org>
Date:	Wed, 3 Sep 2008 19:56:10 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Alok Kataria <akataria@...are.com>
cc:	Thomas Gleixner <tglx@...utronix.de>,
	Larry Finger <Larry.Finger@...inger.net>,
	LKML <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, Michael Buesch <mb@...sch.de>,
	Dan Hecht <dhecht@...are.com>
Subject: Re: [PATCH] Fix TSC calibration issues

On Wed, 3 Sep 2008, Alok Kataria wrote:
> 
> As Linus suggested, we should be moving the tsc_read_refs outside of the
> loop, this gives us more accurate TSC calibration when calibrating against
> hpet/pmtimer, since we are now calibrating over a period of 250ms.

Side note: I'd like to change that.

250ms is a _loong_ time. It's a really really long time. It's 
human-noticeable. A quarter of a second at boot is just too long.

We have a couple of options:

 - make the PIT calibration shorter

   I suspect we could easily make the PIT calibration be just 5ms rather
   than 50ms. Yes, yes, it will be less precise, but the PIT counts at
   1.1MHz or something, so we're still talking about 5000+ ticks of the 
   clock.

   So we'll get within a fraction of a percent. We could then decide that 
   _if_ the HPET/PMTIMER matches the PIT, we'll decide to use that as the 
   reference time, because it would possibly have higher accuracy.

 - do other things while calibrating.

   Especially for HPET/PM_TIMER, we could actually do some other stuff 
   while it is calibrating, since those calibrations only depend on the 
   end/beginning being "close enough". This seems like it would be pretty 
   hard to actually do sanely, though (there's still the issue of the 
   HPET/PM_TIMER overflowing, although with 24 bits that should be on the 
   order of several seconds, I dunno)

Anyway, 250ms really is too long.

		Linus
--
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/