From: Ingo Molnar <mingo@elte.hu>
To: Andrew Morton <akpm@osdl.org>
Cc: tglx@linutronix.de, teunis <teunis@wintersgift.com>,
linux-kernel@vger.kernel.org, Dmitry Torokhov <dtor@mail.ru>
Subject: Re: various laptop nagles - any suggestions? (note: 2.6.19-rc2-mm1 but applies to multiple kernels)
Date: Fri, 20 Oct 2006 22:37:31 +0200 [thread overview]
Message-ID: <20061020203731.GA22407@elte.hu> (raw)
In-Reply-To: <20061020121537.dea13469.akpm@osdl.org>
* Andrew Morton <akpm@osdl.org> wrote:
> > > I don't know how many machines will be affected by this, but I'd
> > > expect it's quite a few - the Vaio has a less-than-one-year-old
> > > Intel CPU in it.
> >
> > Is this still the broken lapic issue ?
>
> yup. iirc the standard FC5 SMP kernel runs dog-slowly on that machine
> too.
hm. This is how lapic timer calibration works.
the lapic timer is really simple - it counts down from a value and
generates an irq if that counter reaches 0. Then it starts counting down
again.
the 'count down from' value is programmed via __setup_APIC_LVTT().
we first write a 'really large' number into it (1 billion):
__setup_APIC_LVTT(1000000000);
the unit of counting is '16 system bus cycles'.
i.e. if your system has a system bus of 333 MHz, then a value of 1
billion takes 48 seconds to count down. (so the calibration ought to be
pretty robust in this regard.)
then we use the wait_timer_tick() function, which waits until the PIT
counter reaches 0 (which is attached to the PIT whose frequency we know
and thus the PIT is already programmed correctly). Hence by calling
wait_timer_tick() we can generate a delay of one jiffy - and we can read
out the current lapic timer count and determine the calibration factor.
then we calculate the result as:
result = (tt1-tt2)*APIC_DIVISOR/LOOPS;
where tt1 is the counter before we start calibration, tt2 is the lapic
timer counter after we did calibration. (APIC_DIVISOR is 16)
i dont see where the error is - but there must be some calibration
problem as your system shows a systematic 1:60 difference between
expected and real lapic timer frequency.
Ingo
next prev parent reply other threads:[~2006-10-20 20:38 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-19 16:05 various laptop nagles - any suggestions? (note: 2.6.19-rc2-mm1 but applies to multiple kernels) teunis
2006-10-20 2:41 ` Andrew Morton
2006-10-20 16:30 ` teunis
2006-10-20 18:07 ` Andrew Morton
2006-10-20 18:13 ` Thomas Gleixner
2006-10-20 18:26 ` Andrew Morton
2006-10-20 18:37 ` Thomas Gleixner
2006-10-20 18:46 ` Thomas Gleixner
2006-10-20 19:15 ` Andrew Morton
2006-10-20 20:37 ` Ingo Molnar [this message]
2006-10-20 20:54 ` Andrew Morton
2006-10-20 20:56 ` Ingo Molnar
2006-10-21 1:25 ` Andrew Morton
2006-10-21 9:49 ` Thomas Gleixner
2006-10-22 21:22 ` Thomas Gleixner
2006-11-08 7:19 ` Andrew Morton
2006-11-08 22:28 ` Thomas Gleixner
2006-10-21 14:52 ` Arjan van de Ven
2006-10-20 19:13 ` Dmitry Torokhov
2006-10-20 22:26 ` teunis
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=20061020203731.GA22407@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@osdl.org \
--cc=dtor@mail.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=teunis@wintersgift.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.