From: Linus Torvalds <torvalds@linux-foundation.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Larry Finger <Larry.Finger@lwfinger.net>,
LKML <linux-kernel@vger.kernel.org>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
Alok Kataria <akataria@vmware.com>, Michael Buesch <mb@bu3sch.de>
Subject: Re: Regression in 2.6.27 caused by commit bfc0f59
Date: Mon, 1 Sep 2008 15:16:47 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.1.10.0809011504200.12958@nehalem.linux-foundation.org> (raw)
In-Reply-To: <alpine.LFD.1.10.0809012114050.3243@apollo.tec.linutronix.de>
On Mon, 1 Sep 2008, Thomas Gleixner wrote:
>
> If the PIT interrupts are delayed by SMM code
Btw, this sentence of yours just doesn't seem to make much sense.
The thing is, the calibration code doesn't even use interrupts. It just
reads the PIT timer value.
And the thing is, the 64-bit code really does things that the 32-bit code
does _not_ do.
Just as an example, the old 32-bit code (the thing that was deleted) tried
to actually round things correctly, while the 64-bit code does not. Look
at what the 64-bit code does:
outb((inb(0x61) & ~0x02) | 0x01, 0x61);
outb(0xb0, 0x43);
outb((CLOCK_TICK_RATE / (1000 / 50)) & 0xff, 0x42);
outb((CLOCK_TICK_RATE / (1000 / 50)) >> 8, 0x42);
tr1 = get_cycles();
while ((inb(0x61) & 0x20) == 0);
tr2 = get_cycles();
and notice three things:
- no comments (can you actually see what it does?)
- no rounding of the inevitable errors of trying to wait 1/50th of a
second
- not a single try to even account for the fact that there might be
things going on that perturb the value.
Now, look at what the 32-bit code _used_ to do. The good code. The code
that was _deleted_.
Really. I don't think you really even looked. It did:
/* run 3 times to ensure the cache is warm and to get an accurate reading */
for (i = 0; i < 3; i++) {
mach_prepare_counter();
rdtscll(start);
mach_countup(&count);
rdtscll(end);
.. ignore bad values ..
/*
* We want the minimum time of all runs in case one of them
* is inaccurate due to SMI or other delay
*/
delta64 = min(delta64, (end - start));
}
and if you actually look at those counter things, you'll see:
#define CALIBRATE_TIME_MSEC 30 /* 30 msecs */
#define CALIBRATE_LATCH \
((CLOCK_TICK_RATE * CALIBRATE_TIME_MSEC + 1000/2)/1000)
static inline void mach_prepare_counter(void)
{
/* Set the Gate high, disable speaker */
outb((inb(0x61) & ~0x02) | 0x01, 0x61);
/*
* Now let's take care of CTC channel 2
*
* Set the Gate high, program CTC channel 2 for mode 0,
* (interrupt on terminal count mode), binary count,
* load 5 * LATCH count, (LSB and MSB) to begin countdown.
*
* Some devices need a delay here.
*/
outb(0xb0, 0x43); /* binary, mode 0, LSB/MSB, Ch 2 */
outb_p(CALIBRATE_LATCH & 0xff, 0x42); /* LSB of count */
outb_p(CALIBRATE_LATCH >> 8, 0x42); /* MSB of count */
}
ie look how it actually tries to round to the nearest latch value, an how
it actually comments on what it is doing.
Now, which piece of code is better?
Honestly?
Have you tried the better version (for example, boot a 32-bit kernel
_before_ the unification on that machine to try).
Linus
next prev parent reply other threads:[~2008-09-01 22:17 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-31 22:54 Larry Finger
2008-09-01 11:14 ` Thomas Gleixner
2008-09-01 15:37 ` Larry Finger
2008-09-01 17:49 ` Thomas Gleixner
2008-09-01 17:44 ` Larry Finger
2008-09-01 18:31 ` Thomas Gleixner
2008-09-01 19:10 ` Linus Torvalds
2008-09-01 20:07 ` Thomas Gleixner
2008-09-01 21:30 ` Thomas Gleixner
2008-09-01 22:02 ` Linus Torvalds
2008-09-01 22:33 ` Thomas Gleixner
2008-09-01 22:56 ` Linus Torvalds
2008-09-01 23:24 ` Thomas Gleixner
2008-09-02 6:37 ` Andi Kleen
2008-09-02 12:21 ` Thomas Gleixner
2008-09-01 22:16 ` Linus Torvalds [this message]
2008-09-01 23:16 ` Thomas Gleixner
2008-09-02 3:18 ` Linus Torvalds
2008-09-02 3:35 ` Linus Torvalds
2008-09-02 4:54 ` Larry Finger
2008-09-02 9:17 ` Alan Cox
2008-09-02 12:15 ` Thomas Gleixner
2008-09-02 15:09 ` Linus Torvalds
2008-09-02 18:14 ` Thomas Gleixner
2008-09-02 18:41 ` Alok Kataria
2008-09-02 21:16 ` Thomas Gleixner
2008-09-02 18:42 ` Linus Torvalds
2008-09-02 21:13 ` Thomas Gleixner
2008-09-02 22:21 ` Linus Torvalds
2008-09-02 23:10 ` Thomas Gleixner
2008-09-03 1:49 ` Linus Torvalds
2008-09-02 22:54 ` [PATCH] Fix TSC calibration issues Thomas Gleixner
2008-09-03 2:14 ` Linus Torvalds
2008-09-03 9:11 ` Thomas Gleixner
2008-09-04 1:14 ` Alok Kataria
2008-09-04 2:56 ` Linus Torvalds
2008-09-04 3:16 ` Arjan van de Ven
2008-09-04 3:59 ` Linus Torvalds
2008-09-04 4:10 ` Arjan van de Ven
2008-09-04 4:20 ` Linus Torvalds
2008-09-04 4:27 ` Arjan van de Ven
2008-09-04 4:25 ` Willy Tarreau
2008-09-04 4:53 ` Linus Torvalds
2008-09-04 5:09 ` Willy Tarreau
2008-09-04 1:18 ` [PATCH] Change warning message in TSC calibration Alok Kataria
2008-09-03 2:51 ` [PATCH] Fix TSC calibration issues Larry Finger
2008-09-03 4:00 ` Linus Torvalds
2008-09-03 4:34 ` Larry Finger
2008-09-05 13:45 ` Regression in 2.6.27 caused by commit bfc0f59 Mark Lord
2008-09-02 17:17 ` Bill Davidsen
2008-09-01 19:36 ` Larry Finger
2008-09-01 20:09 ` Thomas Gleixner
2008-09-01 20:23 ` Larry Finger
2008-09-01 20:45 ` Thomas Gleixner
2008-09-01 18:42 ` Linus Torvalds
2008-09-01 19:08 ` Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.1.10.0809011504200.12958@nehalem.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=Larry.Finger@lwfinger.net \
--cc=akataria@vmware.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mb@bu3sch.de \
--cc=rjw@sisk.pl \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome