From: Andrew Morton <akpm@osdl.org>
To: Ingo Molnar <mingo@elte.hu>
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 13:54:50 -0700 [thread overview]
Message-ID: <20061020135450.6794a2bb.akpm@osdl.org> (raw)
In-Reply-To: <20061020203731.GA22407@elte.hu>
On Fri, 20 Oct 2006 22:37:31 +0200
Ingo Molnar <mingo@elte.hu> wrote:
>
> * 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.
>
Oh. I thought the problem was that the timer stops when the CPU is idle.
Maybe I misremembered. I'll try `idle=poll'.
next prev parent reply other threads:[~2006-10-20 20:55 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
2006-10-20 20:54 ` Andrew Morton [this message]
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=20061020135450.6794a2bb.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=dtor@mail.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--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.