[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.1.10.0809032041130.3515@nehalem.linux-foundation.org>
Date: Wed, 3 Sep 2008 20:59:05 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Arjan van de Ven <arjan@...radead.org>
cc: Alok Kataria <akataria@...are.com>,
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, Arjan van de Ven wrote:
>
> but at some point, even doing things in parallel/asynchronous isn't
> helping, "parallel shit is still shit" :)
Well, the thing is, you can't call ti "shit" when the fact is that we
don't have any other options than to wait.
The only frequency we can trust on 99% of all machines is the PIT, and
it's a very uncomfortable programming model due to all the history (it is
one of the few truly 8-bit things left in a modern PC). The other options
are just not reliably there, or are known to not have a stable frequency.
So how would you suggest we do it? Lowering the wait to 5ms (times 5, so
it's really 25ms, although we can probably stop early if the first
iterations are very consistent) will work, but it _will_ reduce precision.
And it's still real time.
But we simply don't have alternatives. That 'shit' is originally from the
company you work for, btw, and while it was good for its time, the
replacement (HPET) was horribly misdesigned by the same company, and is
deficient in many ways (not the least of which is the idiotic enumeration:
another ACPI braindamage), and it often isn't even exposed.
As a result, the PIT remains to this day the most reliable source of a
reference timer. That includes even on really modern machines (ie the one
I have from Intel that contains hardware not even released yet!).
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/
Powered by blists - more mailing lists