I just noticed major interactivity problems whilst ogging one of my
cds. X (which is running at a nice of 0) stuttered in its display
uptdates (eg: ogging on two seperate machines but displaying on one,
the progress display of the much faster box would come in spurts until
I ^z the ogg on the box running X). Keyboard input also stutters
and the nfs connection (over which I was encoding from the X running
box) eventually gave up the ghost and I got lots of 'server not
responding, timed out' msgs.
Playing Heroes3 was also impossible until I ran it under nice -n 1.
Doh. :/ This is the first time this has been so bad that I've felt
it was worth writing about. :/
Systems:
X: P3-700 with 256MB RAM, half of it free running Debian sarge (libc
2.3.2 and X 4.2.1.1) and 2.6.0-t9-mm3.
SSH: Athlon XP 2500+ with 512MB of RAM with all but 46MB free running
the same version of Debian but with 2.6.0-t9-mm2.
--
From the people who brought you burnt villages in Vietnam...
http://news.independent.co.uk/world/middle_east/story.jsp?story=452375
CaT wrote:
> I just noticed major interactivity problems whilst ogging one of my
[...]
> Doh. :/ This is the first time this has been so bad that I've felt
> it was worth writing about. :/
Yup, I was using a patched mm3 so I wanted to try the plain one, but due
to your post, I can conclude it really is mm3 which is really bad. I
noticed this as well. Using Nick's CPU scheduler things are not thaaat
bad, but still far from mm2. I think there is some major problem
introduced to mm3. Without Nicks patch doing an emerge/compiling, even
my mouse heavily stutters like hell, regradless of the used io
scheduler. With Nick's patch the mouse is rather OK, but the rest if the
system is still not really usable. It is not a HD problem...
Going back to mm2 (patched mm2) and everything it fine again.
Athlon XP 1900MHz
1GB DDR RAM
NFORCE2 Chipset
Prakash
"Prakash K. Cheemplavam" <[email protected]> wrote:
>
> CaT wrote:
>
> > I just noticed major interactivity problems whilst ogging one of my
>
"ogging"?
> Going back to mm2 (patched mm2) and everything it fine again.
Two things to try, please:
a) Is the problem from Linus's tree? Try 2.6.0-test9 plus
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test9/2.6.0-test9-mm3/broken-out/linus.patch
b) The only significant scheduler change in mm3 was
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test9/2.6.0-test9-mm3/broken-out/context-switch-accounting-fix.patch
So please try -mm3 with the above patch reverted with
patch -R -p1 < context-switch-accounting-fix.patch
Thanks.
Arnaldo Carvalho de Melo <[email protected]> wrote:
>
> Em Sun, Nov 16, 2003 at 01:42:31PM -0800, Andrew Morton escreveu:
> > "Prakash K. Cheemplavam" <[email protected]> wrote:
> > >
> > > CaT wrote:
> > >
> > > > I just noticed major interactivity problems whilst ogging one of my
> > >
> >
> > "ogging"?
>
> To Ogg: to oggify, to convert some digital sound file to the .ogg format
>
This much I know. But it's not exactly a tightly defined and repeatable
workload. Oh well.
Em Sun, Nov 16, 2003 at 01:42:31PM -0800, Andrew Morton escreveu:
> "Prakash K. Cheemplavam" <[email protected]> wrote:
> >
> > CaT wrote:
> >
> > > I just noticed major interactivity problems whilst ogging one of my
> >
>
> "ogging"?
To Ogg: to oggify, to convert some digital sound file to the .ogg format
8)
- Arnaldo
On Sun, Nov 16, 2003 at 02:13:42PM -0800, Andrew Morton wrote:
> Arnaldo Carvalho de Melo <[email protected]> wrote:
> > Em Sun, Nov 16, 2003 at 01:42:31PM -0800, Andrew Morton escreveu:
> > > "Prakash K. Cheemplavam" <[email protected]> wrote:
> > > > CaT wrote:
> > > >
> > > > > I just noticed major interactivity problems whilst ogging one of my
> > >
> > > "ogging"?
> >
> > To Ogg: to oggify, to convert some digital sound file to the .ogg format
>
> This much I know. But it's not exactly a tightly defined and repeatable
> workload. Oh well.
I can't do much testing atm but the similar symptoms happen whilst running
Heroes3 which tends to suck CPU so I think mp3 encoding would work just
aswell or anything else that sucks all the CPU it can.
Prakash also reported similar problems whilst compiling the kernel. This is
something I can duplicate also. As my kernel compiles the system can't
even keep up with my typing.
--
From the people who brought you burnt villages in Vietnam...
http://news.independent.co.uk/world/middle_east/story.jsp?story=452375
I also had problems with -mm3.
Now I am using the latest tree from linus with no problems.
P.S.
Sorry but I have no time to try mm3 with the patch reverted.
Panagiotis Papadakos
On Sun, 16 Nov 2003, Andrew Morton wrote:
> "Prakash K. Cheemplavam" <[email protected]> wrote:
> >
> > CaT wrote:
> >
> > > I just noticed major interactivity problems whilst ogging one of my
> >
>
> "ogging"?
>
> > Going back to mm2 (patched mm2) and everything it fine again.
>
> Two things to try, please:
>
> a) Is the problem from Linus's tree? Try 2.6.0-test9 plus
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test9/2.6.0-test9-mm3/broken-out/linus.patch
>
> b) The only significant scheduler change in mm3 was
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test9/2.6.0-test9-mm3/broken-out/context-switch-accounting-fix.patch
>
> So please try -mm3 with the above patch reverted with
>
> patch -R -p1 < context-switch-accounting-fix.patch
>
>
> Thanks.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Mon, 2003-11-17 at 08:42, Andrew Morton wrote:
> Two things to try, please:
>
> a) Is the problem from Linus's tree? Try 2.6.0-test9 plus
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test9/2.6.0-test9-mm3/broken-out/linus.patch
>
> b) The only significant scheduler change in mm3 was
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test9/2.6.0-test9-mm3/broken-out/context-switch-accounting-fix.patch
>
> So please try -mm3 with the above patch reverted with
>
> patch -R -p1 < context-switch-accounting-fix.patch
>
Hi Andrew,
This is also easily reproducible here with just a kernel compile.
I have tried both a) and b) with b) not changing anything, but a) seems
to work... Anything more to try?
Gawain
Gawain Lynch <[email protected]> wrote:
>
> On Mon, 2003-11-17 at 08:42, Andrew Morton wrote:
> > Two things to try, please:
> >
> > a) Is the problem from Linus's tree? Try 2.6.0-test9 plus
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test9/2.6.0-test9-mm3/broken-out/linus.patch
> >
> > b) The only significant scheduler change in mm3 was
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test9/2.6.0-test9-mm3/broken-out/context-switch-accounting-fix.patch
> >
> > So please try -mm3 with the above patch reverted with
> >
> > patch -R -p1 < context-switch-accounting-fix.patch
> >
>
> Hi Andrew,
>
> This is also easily reproducible here with just a kernel compile.
>
> I have tried both a) and b) with b) not changing anything, but a) seems
> to work... Anything more to try?
>
Your report has totally confused me. Are you saying that the jerkiness is
caused by linus.patch? Or not? Pleas try again ;)
On Mon, 2003-11-17 at 13:49, Andrew Morton wrote:
> Gawain Lynch <[email protected]> wrote:
> >
> > On Mon, 2003-11-17 at 08:42, Andrew Morton wrote:
> > > Two things to try, please:
> > >
> > > a) Is the problem from Linus's tree? Try 2.6.0-test9 plus
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test9/2.6.0-test9-mm3/broken-out/linus.patch
> > >
> > > b) The only significant scheduler change in mm3 was
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test9/2.6.0-test9-mm3/broken-out/context-switch-accounting-fix.patch
> > >
> > > So please try -mm3 with the above patch reverted with
> > >
> > > patch -R -p1 < context-switch-accounting-fix.patch
> > >
> >
> > Hi Andrew,
> >
> > This is also easily reproducible here with just a kernel compile.
> >
> > I have tried both a) and b) with b) not changing anything, but a) seems
> > to work... Anything more to try?
> >
>
> Your report has totally confused me. Are you saying that the jerkiness is
> caused by linus.patch? Or not? Pleas try again ;)
Sorry that would be the "several too many" glasses of wine last night...
;)
I do NOT see the interactivity problems with linus.patch.
I DO see the problem with -mm3
I DO see the problem with context-switch-accounting-fix.patch backed
out...
On Sunday 16 November 2003 21:49, Andrew Morton wrote:
>Gawain Lynch <[email protected]> wrote:
>> On Mon, 2003-11-17 at 08:42, Andrew Morton wrote:
>> > Two things to try, please:
>> >
>> > a) Is the problem from Linus's tree? Try 2.6.0-test9 plus
>> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2
>> >.6.0-test9/2.6.0-test9-mm3/broken-out/linus.patch
>> >
>> > b) The only significant scheduler change in mm3 was
>> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2
>> >.6.0-test9/2.6.0-test9-mm3/broken-out/context-switch-accounting-f
>> >ix.patch
>> >
>> > So please try -mm3 with the above patch reverted with
>> >
>> > patch -R -p1 < context-switch-accounting-fix.patch
>>
>> Hi Andrew,
>>
>> This is also easily reproducible here with just a kernel compile.
>>
>> I have tried both a) and b) with b) not changing anything, but a)
>> seems to work... Anything more to try?
>
>Your report has totally confused me. Are you saying that the
> jerkiness is caused by linus.patch? Or not? Pleas try again ;)
In defense of this code, I ran -mm3 with the deadline elevator for
about 3 days and was very happy with the interactivity. Now I've
been running with the elevator=cfq for most of the day, and it also
seems to be pretty responsive. The default as wasn't, at least for
-mm2, and I haven't tried it yet for -mm3. Should I, and report back
in a day or so so that you've got reports from an otherwise identical
system to compare?
We need a test suite for this :)
--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
Gene Heskett wrote:
>On Sunday 16 November 2003 21:49, Andrew Morton wrote:
>
>>Gawain Lynch <[email protected]> wrote:
>>
>>>On Mon, 2003-11-17 at 08:42, Andrew Morton wrote:
>>>
>>>>Two things to try, please:
>>>>
>>>>a) Is the problem from Linus's tree? Try 2.6.0-test9 plus
>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2
>>>>.6.0-test9/2.6.0-test9-mm3/broken-out/linus.patch
>>>>
>>>>b) The only significant scheduler change in mm3 was
>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2
>>>>.6.0-test9/2.6.0-test9-mm3/broken-out/context-switch-accounting-f
>>>>ix.patch
>>>>
>>>> So please try -mm3 with the above patch reverted with
>>>>
>>>> patch -R -p1 < context-switch-accounting-fix.patch
>>>>
>>>Hi Andrew,
>>>
>>>This is also easily reproducible here with just a kernel compile.
>>>
>>>I have tried both a) and b) with b) not changing anything, but a)
>>>seems to work... Anything more to try?
>>>
>>Your report has totally confused me. Are you saying that the
>>jerkiness is caused by linus.patch? Or not? Pleas try again ;)
>>
>
>In defense of this code, I ran -mm3 with the deadline elevator for
>about 3 days and was very happy with the interactivity. Now I've
>been running with the elevator=cfq for most of the day, and it also
>seems to be pretty responsive. The default as wasn't, at least for
>-mm2, and I haven't tried it yet for -mm3. Should I, and report back
>in a day or so so that you've got reports from an otherwise identical
>system to compare?
>
I think you might have confused Andrew a bit more ;)
To start with, you are talking about IO schedulers, while the thread
is about CPU interactivity.
The problem here looks like something that is caused by something in mm3,
not in mm2, not linus.patch, and not context-switch-accounting-fix.patch.
Off topic: it would be good if you could try the as disk scheduler in mm3.
I recall you had some problems with it earlier, but they should be fixed in
mm3. Thanks.
>
>We need a test suite for this :)
>
Subjective reports from our base of beta testers has proven to be the
best thing.
On Sunday 16 November 2003 23:19, Nick Piggin wrote:
>
>I think you might have confused Andrew a bit more ;)
>
>To start with, you are talking about IO schedulers, while the thread
>is about CPU interactivity.
I wasn't aware that such performance issues were divorced. In my
admitted limited view, a laggy mouse is a laggy mouse, and its due to
irq latency in achieving the context switch to service the mouses
data. To me, its sorta like 2=2. :)
>The problem here looks like something that is caused by something in
> mm3, not in mm2, not linus.patch, and not
> context-switch-accounting-fix.patch.
>
>
>Off topic: it would be good if you could try the as disk scheduler
> in mm3. I recall you had some problems with it earlier, but they
> should be fixed in mm3. Thanks.
Ok Nick. I'll reboot tomorrow without the elevator argument. Right
now, amanda is fixin to be fired off in about 25 minutes and I want
to see how badly its estimate phase hogs the machine using the cfq
scheduler. With the -mm2 as, it was almost psychedelic to watch the
mouse move.
Also off topic re mouse performance, and I expect this is an X issue,
but when its been blanked because I'm typing, it takes about a full
seconds worth of hand waving before it becomes visible again. This
is an X issue and I should go away, right?
>
>>We need a test suite for this :)
>
>Subjective reports from our base of beta testers has proven to be
> the best thing.
So beit. I guess I must be one of those. (-:
--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
Gene Heskett wrote:
>On Sunday 16 November 2003 23:19, Nick Piggin wrote:
>
>>I think you might have confused Andrew a bit more ;)
>>
>>To start with, you are talking about IO schedulers, while the thread
>>is about CPU interactivity.
>>
>
>I wasn't aware that such performance issues were divorced. In my
>admitted limited view, a laggy mouse is a laggy mouse, and its due to
>irq latency in achieving the context switch to service the mouses
>data. To me, its sorta like 2=2. :)
>
I guess its mostly due to scheduling latency. I think IRQ latency is
generally very good these days.
Scheduling latency caused not by long critical sections in the kernel,
but having things scheduled in front of you (X) for a long time.
>
>>The problem here looks like something that is caused by something in
>>mm3, not in mm2, not linus.patch, and not
>>context-switch-accounting-fix.patch.
>>
>>
>>Off topic: it would be good if you could try the as disk scheduler
>>in mm3. I recall you had some problems with it earlier, but they
>>should be fixed in mm3. Thanks.
>>
>
>Ok Nick. I'll reboot tomorrow without the elevator argument. Right
>now, amanda is fixin to be fired off in about 25 minutes and I want
>to see how badly its estimate phase hogs the machine using the cfq
>scheduler. With the -mm2 as, it was almost psychedelic to watch the
>mouse move.
>
OK thanks. I think this problem you were seeing _was_ interrupt latency
due to AS doing millions of WARNs. It should be fixed in mm3.
>
>Also off topic re mouse performance, and I expect this is an X issue,
>but when its been blanked because I'm typing, it takes about a full
>seconds worth of hand waving before it becomes visible again. This
>is an X issue and I should go away, right?
>
Sounds like it.
Andrew Morton <[email protected]> writes:
> Gawain Lynch <[email protected]> wrote:
> >
> > On Mon, 2003-11-17 at 08:42, Andrew Morton wrote:
> > > Two things to try, please:
> > >
> > > a) Is the problem from Linus's tree? Try 2.6.0-test9 plus
> > >
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test9/2.6.0-test9-mm3/broken-out/linus.patch
> > >
> > > b) The only significant scheduler change in mm3 was
> > >
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test9/2.6.0-test9-mm3/broken-out/context-switch-accounting-fix.patch
> > >
> > > So please try -mm3 with the above patch reverted with
> > >
> > > patch -R -p1 < context-switch-accounting-fix.patch
> > >
> >
> > Hi Andrew,
> >
> > This is also easily reproducible here with just a kernel compile.
> >
> > I have tried both a) and b) with b) not changing anything, but a)
seems
> > to work... Anything more to try?
> >
>
> Your report has totally confused me. Are you saying that the
jerkiness is
> caused by linus.patch? Or not? Pleas try again ;)
>
I've found that neither linus.patch nor
context-switch-accounting-fix.patch is causing the problem, but rather
acpi-pm-timer-fixes.patch & acpi-pm-timer.patch
With these applied my cpu (athlon64) is detected as 0.0Mhz, bogomips
drops to 50% and anything cpu intensive destroys interactivity. Revert
them and performance is back at -mm2 level.
--
Ronny V. Vindenes <[email protected]>
Ronny V. Vindenes wrote:
> I've found that neither linus.patch nor
> context-switch-accounting-fix.patch is causing the problem, but rather
> acpi-pm-timer-fixes.patch & acpi-pm-timer.patch
>
> With these applied my cpu (athlon64) is detected as 0.0Mhz, bogomips
> drops to 50% and anything cpu intensive destroys interactivity. Revert
> them and performance is back at -mm2 level.
>
Yup, works for me too. Reverting those patches and my machine is smooth
again. :)
Prakash
On Mon, 2003-11-17 at 13:11, Ronny V. Vindenes wrote:
> I've found that neither linus.patch nor
> context-switch-accounting-fix.patch is causing the problem, but rather
> acpi-pm-timer-fixes.patch & acpi-pm-timer.patch
I'm running -mm3 and haven't noticed any interactivity problems as far
as the ACPI PM timer support is *not enabled*. Enabling ACPI PM timer,
makes the system feel rather sluggish.
On Mon, 2003-11-17 at 11:36, Andrew Morton wrote:
> "Ronny V. Vindenes" <[email protected]> wrote:
> > I've found that neither linus.patch nor
> > context-switch-accounting-fix.patch is causing the problem, but rather
> > acpi-pm-timer-fixes.patch & acpi-pm-timer.patch
> >
> > With these applied my cpu (athlon64) is detected as 0.0Mhz, bogomips
> > drops to 50% and anything cpu intensive destroys interactivity. Revert
> > them and performance is back at -mm2 level.
>
> ah hah. Thank you!
>
> Probably the interactivity problems are due to the CPU scheduler thinking
> that the CPU runs at 0Hz. If we can work out why the PM timer patch has
> broken the CPU clock speed detection then all should be well.
Hrmm. I'll look into this.
thanks
-john
"Ronny V. Vindenes" <[email protected]> wrote:
>
> > Your report has totally confused me. Are you saying that the
> jerkiness is
> > caused by linus.patch? Or not? Pleas try again ;)
> >
>
> I've found that neither linus.patch nor
> context-switch-accounting-fix.patch is causing the problem, but rather
> acpi-pm-timer-fixes.patch & acpi-pm-timer.patch
>
> With these applied my cpu (athlon64) is detected as 0.0Mhz, bogomips
> drops to 50% and anything cpu intensive destroys interactivity. Revert
> them and performance is back at -mm2 level.
ah hah. Thank you!
Probably the interactivity problems are due to the CPU scheduler thinking
that the CPU runs at 0Hz. If we can work out why the PM timer patch has
broken the CPU clock speed detection then all should be well.
Hi!
On Monday 17 November 2003 14:12, Prakash K. Cheemplavam wrote:
> Ronny V. Vindenes wrote:
> > I've found that neither linus.patch nor
> > context-switch-accounting-fix.patch is causing the problem, but rather
> > acpi-pm-timer-fixes.patch & acpi-pm-timer.patch
> >
> > With these applied my cpu (athlon64) is detected as 0.0Mhz, bogomips
> > drops to 50% and anything cpu intensive destroys interactivity. Revert
> > them and performance is back at -mm2 level.
>
> Yup, works for me too. Reverting those patches and my machine is smooth
> again. :)
>
> Prakash
I was able to reproduce the interactivity problem, too. My simple testcase
was:
1. open a KDE Konsole
2. execute "while true; do a=2; done" in the Konsole
3. Move the Konsole window.
With test9-mm3 booted with "clock=pit" or "clock=pmtmr" moving the window was
very sluggish... Booted with "clock=tsc" made it work fine again. (Btw. which
kind of hardware is needed to make "clock=hpet" work?)
The problem is that sched_clock() uses the TSC if the hardware supports it.
But the needed scaling factors are only initialized in init_tsc() and
init_hpet(). So there are 2 possibilities to fix this:
1. Call the neccessary parts of init_tsc() in init_pmtmr() and init_pit().
2. Use the TSC in sched_clock() only if "clock=tsc" was set.
I've attached a small patch that does the 2nd thing. For me it fixed the
interactivity problem...
The 2nd attached patch adds the .name field to the timer_pmtmr struct. This
makes the kernel to show "Using pmtmr for high-res timesource" instead of
"Using NULL for high-res timesource" when booting...
Andrew, please consider applying the patches...
Btw. the BogoMIPS value is the argument for the __delay() function needed to
wait 1 jiffy. The difference is that the TSC version of this function uses
the clock cycle count as its argument whereas the PMTMR and PIT versions take
the count of loops to wait as their argument. Well, and it seems that each
loop iteration needs 2 clock cycles.
The problem with the shown CPU frequency is, that cpu_khz is only set in
init_tsc() and init_hpet(). But I don't know how this can be fixed without
using the TSC...
Best regards
Thomas
On Mon, 2003-11-17 at 11:46, Thomas Schlichter wrote:
> On Monday 17 November 2003 14:12, Prakash K. Cheemplavam wrote:
> > Ronny V. Vindenes wrote:
> > > I've found that neither linus.patch nor
> > > context-switch-accounting-fix.patch is causing the problem, but rather
> > > acpi-pm-timer-fixes.patch & acpi-pm-timer.patch
> > >
> > > With these applied my cpu (athlon64) is detected as 0.0Mhz, bogomips
> > > drops to 50% and anything cpu intensive destroys interactivity. Revert
> > > them and performance is back at -mm2 level.
> >
> > Yup, works for me too. Reverting those patches and my machine is smooth
> > again. :)
Not configuring the ACPI PM time source in should also work as well.
> I was able to reproduce the interactivity problem, too. My simple testcase
> was:
> 1. open a KDE Konsole
> 2. execute "while true; do a=2; done" in the Konsole
> 3. Move the Konsole window.
>
> With test9-mm3 booted with "clock=pit" or "clock=pmtmr" moving the window was
> very sluggish... Booted with "clock=tsc" made it work fine again. (Btw. which
> kind of hardware is needed to make "clock=hpet" work?)
>
> The problem is that sched_clock() uses the TSC if the hardware supports it.
> But the needed scaling factors are only initialized in init_tsc() and
> init_hpet(). So there are 2 possibilities to fix this:
> 1. Call the neccessary parts of init_tsc() in init_pmtmr() and init_pit().
> 2. Use the TSC in sched_clock() only if "clock=tsc" was set.
As far as sched_clock() goes, I haven't followed its development
closely, but it seem that it is very close to monotonic_clock() in
functionality. The benefit of monotonic_clock is that it is implemented
for each time source (however its not implemented for every arch). For
i386 at least, we may want to make sched_clock just call
monotonic_clock, but I need to look into the details.
> I've attached a small patch that does the 2nd thing. For me it fixed the
> interactivity problem...
That tentatively looks OK to me, but I suspect that sched_clock needs
further work on i386.
> Btw. the BogoMIPS value is the argument for the __delay() function needed to
> wait 1 jiffy. The difference is that the TSC version of this function uses
> the clock cycle count as its argument whereas the PMTMR and PIT versions take
> the count of loops to wait as their argument. Well, and it seems that each
> loop iteration needs 2 clock cycles.
__delay() is called with loops as an argument. calibrate_delay() sets
loops_per_jiffy such that mdelay() and udelay() will delay for the
proper amount of time. BogoMIPS may not line up w/ your cpu frequency,
but don't let that worry you.
> The problem with the shown CPU frequency is, that cpu_khz is only set in
> init_tsc() and init_hpet(). But I don't know how this can be fixed without
> using the TSC...
You're correct, I forgot to initialize cpu_khz in the ACPI PM timesource
init code. This patch fixes that.
thanks for the great testing and feedback!
-john
diff -Nru a/arch/i386/kernel/timers/common.c b/arch/i386/kernel/timers/common.c
--- a/arch/i386/kernel/timers/common.c Mon Nov 17 13:23:43 2003
+++ b/arch/i386/kernel/timers/common.c Mon Nov 17 13:23:43 2003
@@ -137,3 +137,23 @@
}
#endif
+/* calculate cpu_khz */
+void __init init_cpu_khz(void)
+{
+ if (cpu_has_tsc) {
+ unsigned long tsc_quotient = calibrate_tsc();
+ if (tsc_quotient) {
+ /* report CPU clock rate in Hz.
+ * The formula is (10^6 * 2^32) / (2^32 * 1 / (clocks/us)) =
+ * clock/second. Our precision is about 100 ppm.
+ */
+ { unsigned long eax=0, edx=1000;
+ __asm__("divl %2"
+ :"=a" (cpu_khz), "=d" (edx)
+ :"r" (tsc_quotient),
+ "0" (eax), "1" (edx));
+ printk("Detected %lu.%03lu MHz processor.\n", cpu_khz / 1000, cpu_khz % 1000);
+ }
+ }
+ }
+}
diff -Nru a/arch/i386/kernel/timers/timer_cyclone.c b/arch/i386/kernel/timers/timer_cyclone.c
--- a/arch/i386/kernel/timers/timer_cyclone.c Mon Nov 17 13:23:43 2003
+++ b/arch/i386/kernel/timers/timer_cyclone.c Mon Nov 17 13:23:43 2003
@@ -212,27 +212,8 @@
}
}
- /* init cpu_khz.
- * XXX - This should really be done elsewhere,
- * and in a more generic fashion. [email protected]
- */
- if (cpu_has_tsc) {
- unsigned long tsc_quotient = calibrate_tsc();
- if (tsc_quotient) {
- /* report CPU clock rate in Hz.
- * The formula is (10^6 * 2^32) / (2^32 * 1 / (clocks/us)) =
- * clock/second. Our precision is about 100 ppm.
- */
- { unsigned long eax=0, edx=1000;
- __asm__("divl %2"
- :"=a" (cpu_khz), "=d" (edx)
- :"r" (tsc_quotient),
- "0" (eax), "1" (edx));
- printk("Detected %lu.%03lu MHz processor.\n", cpu_khz / 1000, cpu_khz % 1000);
- }
- }
- }
-
+ init_cpu_khz();
+
/* Everything looks good! */
return 0;
}
diff -Nru a/arch/i386/kernel/timers/timer_pm.c b/arch/i386/kernel/timers/timer_pm.c
--- a/arch/i386/kernel/timers/timer_pm.c Mon Nov 17 13:23:43 2003
+++ b/arch/i386/kernel/timers/timer_pm.c Mon Nov 17 13:23:43 2003
@@ -57,14 +57,18 @@
if (value2 == value1)
continue;
if (value2 > value1)
- return 0;
+ goto pm_good;
if ((value2 < value1) && ((value2) < 0xFFF))
- return 0;
+ goto pm_good;
printk(KERN_INFO "PM-Timer had inconsistent results: 0x%#x, 0x%#x - aborting.\n", value1, value2);
return -EINVAL;
}
printk(KERN_INFO "PM-Timer had no reasonable result: 0x%#x - aborting.\n", value1);
return -ENODEV;
+
+pm_good:
+ init_cpu_khz();
+ return 0;
}
static inline u32 cyc2us(u32 cycles)
diff -Nru a/include/asm-i386/timer.h b/include/asm-i386/timer.h
--- a/include/asm-i386/timer.h Mon Nov 17 13:23:43 2003
+++ b/include/asm-i386/timer.h Mon Nov 17 13:23:43 2003
@@ -39,6 +39,7 @@
#endif
extern unsigned long calibrate_tsc(void);
+extern void init_cpu_khz(void);
#ifdef CONFIG_HPET_TIMER
extern struct timer_opts timer_hpet;
extern unsigned long calibrate_tsc_hpet(unsigned long *tsc_hpet_quotient_ptr);
On Mon, 2003-11-17 at 13:27, john stultz wrote:
> On Mon, 2003-11-17 at 11:46, Thomas Schlichter wrote:
> > The problem is that sched_clock() uses the TSC if the hardware supports it.
> > But the needed scaling factors are only initialized in init_tsc() and
> > init_hpet(). So there are 2 possibilities to fix this:
> > 1. Call the neccessary parts of init_tsc() in init_pmtmr() and init_pit().
> > 2. Use the TSC in sched_clock() only if "clock=tsc" was set.
>
> As far as sched_clock() goes, I haven't followed its development
> closely, but it seem that it is very close to monotonic_clock() in
> functionality. The benefit of monotonic_clock is that it is implemented
> for each time source (however its not implemented for every arch). For
> i386 at least, we may want to make sched_clock just call
> monotonic_clock, but I need to look into the details.
Here's a patch that does the above. I'm not very aware of the issues
around the scheduler so I'm not sure if the cost of going off chip to
the cyclone or ACPI PM time sources are just outright, but for the TSC
case monotonic_clock() is basically the same function as sched_clock().
So this might be the best fix for systems not using the TSC as a time
source.
I'd be interested to hear if it has any effect on performance.
thanks
-john
diff -Nru a/arch/i386/kernel/time.c b/arch/i386/kernel/time.c
--- a/arch/i386/kernel/time.c Mon Nov 17 14:36:32 2003
+++ b/arch/i386/kernel/time.c Mon Nov 17 14:36:32 2003
@@ -190,6 +190,12 @@
}
EXPORT_SYMBOL(monotonic_clock);
+/* sched_clock() ~== monotonic_clock() */
+unsigned long long sched_clock(void)
+{
+ return cur_timer->monotonic_clock();
+}
+
/*
* timer_interrupt() needs to keep up the real-time clock,
diff -Nru a/arch/i386/kernel/timers/timer_pit.c b/arch/i386/kernel/timers/timer_pit.c
--- a/arch/i386/kernel/timers/timer_pit.c Mon Nov 17 14:36:32 2003
+++ b/arch/i386/kernel/timers/timer_pit.c Mon Nov 17 14:36:32 2003
@@ -37,7 +37,7 @@
static unsigned long long monotonic_clock_pit(void)
{
- return 0;
+ return (unsigned long long)jiffies * (NSEC_PER_SEC / HZ);
}
static void delay_pit(unsigned long loops)
diff -Nru a/arch/i386/kernel/timers/timer_tsc.c b/arch/i386/kernel/timers/timer_tsc.c
--- a/arch/i386/kernel/timers/timer_tsc.c Mon Nov 17 14:36:32 2003
+++ b/arch/i386/kernel/timers/timer_tsc.c Mon Nov 17 14:36:32 2003
@@ -127,30 +127,6 @@
return base + cycles_2_ns(this_offset - last_offset);
}
-/*
- * Scheduler clock - returns current time in nanosec units.
- */
-unsigned long long sched_clock(void)
-{
- unsigned long long this_offset;
-
- /*
- * In the NUMA case we dont use the TSC as they are not
- * synchronized across all CPUs.
- */
-#ifndef CONFIG_NUMA
- if (unlikely(!cpu_has_tsc))
-#endif
- return (unsigned long long)jiffies * (1000000000 / HZ);
-
- /* Read the Time Stamp Counter */
- rdtscll(this_offset);
-
- /* return the value in ns */
- return cycles_2_ns(this_offset);
-}
-
-
static void mark_offset_tsc(void)
{
unsigned long lost,delay;
john stultz wrote:
> On Mon, 2003-11-17 at 11:46, Thomas Schlichter wrote:
>
>>On Monday 17 November 2003 14:12, Prakash K. Cheemplavam wrote:
>>
>>>Ronny V. Vindenes wrote:
>>>
>>>>I've found that neither linus.patch nor
>>>>context-switch-accounting-fix.patch is causing the problem, but rather
>>>>acpi-pm-timer-fixes.patch & acpi-pm-timer.patch
>>>>
>>>>With these applied my cpu (athlon64) is detected as 0.0Mhz, bogomips
>>>>drops to 50% and anything cpu intensive destroys interactivity. Revert
>>>>them and performance is back at -mm2 level.
>>>
>>>Yup, works for me too. Reverting those patches and my machine is smooth
>>>again. :)
>
>
> Not configuring the ACPI PM time source in should also work as well.
> You're correct, I forgot to initialize cpu_khz in the ACPI PM timesource
> init code. This patch fixes that.
Well I applied your patch without the ones from Thomas Schlichter. Was
is intended like that or should it be on top of Thomas patches?
I haven't tested thouroughly, but on the first impression your patch
didn't make things really better, that's why I stoped testing. I just
did following test:
Running prime95 as task taking 100% CPU) and started up mozilla and
mailer. This took nearly endlessly. Deaktivating ACPI timer and things
are fast again, ie. starting mozilla is like no background task is
runnig. I dunno if it is a not 100% working patch or if it is Nick's
scheduler, which I am using.
Prakash
On Mon, 2003-11-17 at 14:55, john stultz wrote:
> On Mon, 2003-11-17 at 14:51, Prakash K. Cheemplavam wrote:
> > john stultz wrote:
> > > You're correct, I forgot to initialize cpu_khz in the ACPI PM timesource
> > > init code. This patch fixes that.
> >
> > Well I applied your patch without the ones from Thomas Schlichter. Was
> > is intended like that or should it be on top of Thomas patches?
>
> It was to go along side of Thomas' patch. Thomas caught the real issue
> (sched_clock() needs to be switched on use_tsc), but cpu_khz is also
> used in the scheduler, so I just wanted to make sure it was properly set
> as well.
After sending out multiple patches I should have been more clear. Just
to avoid confusion:
* the init_cpu_khz patch goes along side Thomas' patch.
* the more experimental sched_clock() -> monotonic_clock() patch I just
sent out for testing replaces Thomas' patch.
thanks
-john
On Mon, 2003-11-17 at 14:51, Prakash K. Cheemplavam wrote:
> john stultz wrote:
> > You're correct, I forgot to initialize cpu_khz in the ACPI PM timesource
> > init code. This patch fixes that.
>
> Well I applied your patch without the ones from Thomas Schlichter. Was
> is intended like that or should it be on top of Thomas patches?
It was to go along side of Thomas' patch. Thomas caught the real issue
(sched_clock() needs to be switched on use_tsc), but cpu_khz is also
used in the scheduler, so I just wanted to make sure it was properly set
as well.
thanks
-john
On Tuesday 18 November 2003 00:04, john stultz wrote:
> On Mon, 2003-11-17 at 14:55, john stultz wrote:
> > On Mon, 2003-11-17 at 14:51, Prakash K. Cheemplavam wrote:
> > > john stultz wrote:
> > > > You're correct, I forgot to initialize cpu_khz in the ACPI PM
> > > > timesource init code. This patch fixes that.
> > >
> > > Well I applied your patch without the ones from Thomas Schlichter. Was
> > > is intended like that or should it be on top of Thomas patches?
> >
> > It was to go along side of Thomas' patch. Thomas caught the real issue
> > (sched_clock() needs to be switched on use_tsc), but cpu_khz is also
> > used in the scheduler, so I just wanted to make sure it was properly set
> > as well.
>
> After sending out multiple patches I should have been more clear. Just
> to avoid confusion:
>
> * the init_cpu_khz patch goes along side Thomas' patch.
>
> * the more experimental sched_clock() -> monotonic_clock() patch I just
> sent out for testing replaces Thomas' patch.
>
> thanks
> -john
OK, now I was testing both your patches instead of mine.
The init_cpu_khz patch works as expected... THX!
Well, but the sched_clock() -> monotonic_clock() patch seems to have a
problem...
First, everything works smoothly if the PIT or the TSC clock are selected. (It
seems I cannot test the HPET timer due to missing hardware support)
But when booting with the PMTMR clock selected, my Interactivity test fails
again. :-( Maybe there is a problem in the PMTMR's monotonic clock part...?!
Thomas
>
> After sending out multiple patches I should have been more clear. Just
> to avoid confusion:
>
> * the init_cpu_khz patch goes along side Thomas' patch.
>
> * the more experimental sched_clock() -> monotonic_clock() patch I just
> sent out for testing replaces Thomas' patch.
I now tried the second one and it seems to work, tough I am not sure
whether the performance is as good as APCI timer deavt. It seems that
now CPU Hz is not shown anymore. Have a look at my dmesg:
Linux version 2.6.0-test9-love3 (root@tachyon) (gcc-Version 3.3.2
20031022 (Gentoo Linux 3.3.2-r2, propolice)) #16 Tue Nov 18 13:54:04 CET
2003
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000003fff0000 (usable)
BIOS-e820: 000000003fff0000 - 000000003fff3000 (ACPI NVS)
BIOS-e820: 000000003fff3000 - 0000000040000000 (ACPI data)
BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
127MB HIGHMEM available.
896MB LOWMEM available.
On node 0 totalpages: 262128
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 225280 pages, LIFO batch:16
HighMem zone: 32752 pages, LIFO batch:7
DMI 2.2 present.
ACPI: RSDP (v000 Nvidia ) @ 0x000f6b60
ACPI: RSDT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x3fff3000
ACPI: FADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x3fff3040
ACPI: MADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x3fff79c0
ACPI: DSDT (v001 NVIDIA AWRDACPI 0x00001000 MSFT 0x0100000d) @ 0x00000000
ACPI: PM-Timer IO Port: 0x4008
Building zonelist for node : 0
Kernel command line: root=/dev/hde6 hdg=none vga=0x51A
video=vesa:mtrr,ywrap elevator=cfq
ide_setup: hdg=none
current: c0499a60
current->thread_info: c0528000
Initializing CPU#0
PID hash table entries: 4096 (order 12: 32768 bytes)
Using <NULL> for high-res timesource
Console: colour dummy device 80x25
Memory: 1032156k/1048512k available (3217k kernel code, 15404k reserved,
1031k data, 160k init, 131008k highmem)
zapping low mappings.
Calibrating delay loop... 1990.65 BogoMIPS
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
checking if image is initramfs...it isn't (ungzip failed); looks like an
initrd
Freeing initrd memory: 304k freed
CPU: After generic identify, caps: 0383fbff c1c3fbff 00000000 00000000
CPU: After vendor identify, caps: 0383fbff c1c3fbff 00000000 00000000
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After all inits, caps: 0383fbff c1c3fbff 00000000 00000020
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: AMD Athlon(tm) stepping 01
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfb420, last bus=2
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20031002
ACPI: IRQ 9 was Edge Triggered, setting to Level Triggerd
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGPB._PRT]
ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 *5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNK2] (IRQs 3 4 5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNK3] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNK4] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNK5] (IRQs 3 4 5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LUBA] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LUBB] (IRQs 3 4 *5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LMAC] (IRQs 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LAPU] (IRQs 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LACI] (IRQs 3 4 *5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LMCI] (IRQs 3 4 5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LSMB] (IRQs 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LUB2] (IRQs 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LFIR] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [L3CM] (IRQs 3 4 5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LIDE] (IRQs 3 4 5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [APC1] (IRQs *16)
ACPI: PCI Interrupt Link [APC2] (IRQs 17)
ACPI: PCI Interrupt Link [APC3] (IRQs *18)
ACPI: PCI Interrupt Link [APC4] (IRQs *19)
ACPI: PCI Interrupt Link [APCE] (IRQs 16)
ACPI: PCI Interrupt Link [APCF] (IRQs 20 21 22)
ACPI: PCI Interrupt Link [APCG] (IRQs 20 21 22)
ACPI: PCI Interrupt Link [APCH] (IRQs 20 21 22)
ACPI: PCI Interrupt Link [APCI] (IRQs 20 21 22)
ACPI: PCI Interrupt Link [APCJ] (IRQs 20 21 22)
ACPI: PCI Interrupt Link [APCK] (IRQs 20 21 22)
ACPI: PCI Interrupt Link [APCS] (IRQs *23)
ACPI: PCI Interrupt Link [APCL] (IRQs 20 21 22)
ACPI: PCI Interrupt Link [APCM] (IRQs 20 21 22)
ACPI: PCI Interrupt Link [AP3C] (IRQs 20 21 22)
ACPI: PCI Interrupt Link [APCZ] (IRQs 20 21 22)
Linux Plug and Play Support v0.97 (c) Adam Belay
SCSI subsystem initialized
drivers/usb/core/usb.c: registered new driver usbfs
drivers/usb/core/usb.c: registered new driver hub
ACPI: PCI Interrupt Link [LSMB] enabled at IRQ 10
ACPI: PCI Interrupt Link [LUBA] enabled at IRQ 11
ACPI: PCI Interrupt Link [LUBB] enabled at IRQ 5
ACPI: PCI Interrupt Link [LUB2] enabled at IRQ 10
ACPI: PCI Interrupt Link [LMAC] enabled at IRQ 10
ACPI: PCI Interrupt Link [LAPU] enabled at IRQ 10
ACPI: PCI Interrupt Link [LACI] enabled at IRQ 5
ACPI: PCI Interrupt Link [LFIR] enabled at IRQ 11
ACPI: PCI Interrupt Link [LNK4] enabled at IRQ 11
ACPI: PCI Interrupt Link [LNK1] enabled at IRQ 5
ACPI: PCI Interrupt Link [LNK3] enabled at IRQ 11
PCI: Using ACPI for IRQ routing
PCI: if you experience problems, try using option 'pci=noacpi' or even
'acpi=off'
vesafb: framebuffer at 0xc0000000, mapped to 0xf8808000, size 16384k
vesafb: mode is 1280x1024x16, linelength=2560, pages=1
vesafb: protected mode interface info at c000:ea60
vesafb: scrolling: redraw
vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0
fb0: VESA VGA frame buffer device
Machine check exception polling timer started.
IA-32 Microcode Update Driver: v1.13 <[email protected]>
apm: BIOS version 1.2 Flags 0x07 (Driver version 1.16ac)
apm: overridden by ACPI.
highmem bounce pool size: 64 pages
devfs: v1.22 (20021013) Richard Gooch ([email protected])
devfs: boot_options: 0x1
Installing knfsd (copyright (C) 1996 [email protected]).
NTFS driver 2.1.4 [Flags: R/W].
udf: registering filesystem
SGI XFS for Linux with large block numbers, no debug enabled
ACPI: Power Button (FF) [PWRF]
ACPI: Fan [FAN] (on)
ACPI: Processor [CPU0] (supports C1)
ACPI: Thermal Zone [THRM] (41 C)
bootsplash 3.1.3-2003/11/14: looking for picture.... silentjpeg size
155838 bytes, found (1280x1024, 155850 bytes, v3).
Console: switching to colour frame buffer device 153x58
pty: 256 Unix98 ptys configured
Real Time Clock Driver v1.12
Non-volatile memory driver v1.2
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
loop: loaded (max 8 devices)
Linux video capture interface: v1.00
DriverInitialize MAC address = ff:ff:ff:ff:ff:ff:00:00
DriverInitialize key =
ff ff ff ff
ff ff ff ff
ff ff ff ff
ff ff ff ff
DVB: registering new adapter (Technisat SkyStar2 driver).
DVB: registering frontend 0:0 (Zarlink MT312)...
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
NFORCE2: IDE controller at PCI slot 0000:00:09.0
NFORCE2: chipset revision 162
NFORCE2: not 100% native mode: will probe irqs later
NFORCE2: 0000:00:09.0 (rev a2) UDMA133 controller
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
hda: _NEC DV-5800A, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hdc: LITE-ON LTR-16102B, ATAPI CD/DVD-ROM drive
hdd: IOMEGA ZIP 100 ATAPI, ATAPI FLOPPY drive
ide1 at 0x170-0x177,0x376 on irq 15
SiI3112 Serial ATA: IDE controller at PCI slot 0000:01:0b.0
SiI3112 Serial ATA: chipset revision 2
SiI3112 Serial ATA: 100% native mode on irq 11
ide2: MMIO-DMA at 0xf9842000-0xf9842007, BIOS settings: hde:pio,
hdf:pio
ide3: MMIO-DMA at 0xf9842008-0xf984200f, BIOS settings: hdg:pio,
hdh:pio
hde: SAMSUNG SP1614N, ATA DISK drive
ide2 at 0xf9842080-0xf9842087,0xf984208a on irq 11
hde: max request size: 7KiB
hde: 312581808 sectors (160041 MB) w/8192KiB Cache, CHS=19457/255/63,
UDMA(100)
/dev/ide/host2/bus0/target0/lun0: p1 p2 p3 < p5 p6 p7 p8 >
hda: ATAPI 48X DVD-ROM drive, 512kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
hdc: ATAPI 40X CD-ROM CD-R/RW drive, 2048kB Cache, DMA
ide-floppy driver 0.99.newide
hdd: No disk in drive
hdd: 98304kB, 32/64/96 CHS, 4096 kBps, 512 sector size, 2941 rpm
ohci1394: $Rev: 1045 $ Ben Collins <[email protected]>
PCI: Setting latency timer of device 0000:00:0d.0 to 64
ohci1394_0: OHCI-1394 1.1 (PCI): IRQ=[11] MMIO=[cc084000-cc0847ff] Max
Packet=[2048]
ohci1394_0: SelfID received outside of bus reset sequence
video1394: Installed video1394 module
raw1394: /dev/raw1394 device initialized
Console: switching to colour frame buffer device 153x58
ehci_hcd 0000:00:02.2: EHCI Host Controller
PCI: Setting latency timer of device 0000:00:02.2 to 64
ehci_hcd 0000:00:02.2: irq 10, pci mem f984a000
ehci_hcd 0000:00:02.2: new USB bus registered, assigned bus number 1
PCI: cache line size of 64 is not supported by device 0000:00:02.2
ehci_hcd 0000:00:02.2: USB 2.0 enabled, EHCI 1.00, driver 2003-Jun-13
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 6 ports detected
ohci_hcd: 2003 Oct 13 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
ohci_hcd: block sizes: ed 64 td 64
ohci_hcd 0000:00:02.0: OHCI Host Controller
PCI: Setting latency timer of device 0000:00:02.0 to 64
ohci_hcd 0000:00:02.0: irq 11, pci mem f984c000
ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 3 ports detected
ohci_hcd 0000:00:02.1: OHCI Host Controller
PCI: Setting latency timer of device 0000:00:02.1 to 64
ohci_hcd 0000:00:02.1: irq 5, pci mem f984e000
ohci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 3
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 3 ports detected
drivers/usb/host/uhci-hcd.c: USB Universal Host Controller Interface
driver v2.1
drivers/usb/core/usb.c: registered new driver usblp
drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
Initializing USB Mass Storage driver...
drivers/usb/core/usb.c: registered new driver usb-storage
USB Mass Storage support registered.
drivers/usb/core/usb.c: registered new driver usbscanner
drivers/usb/image/scanner.c: 0.4.15:USB Scanner Driver
mice: PS/2 mouse device common for all mice
input: ImPS/2 Generic Wheel Mouse on isa0060/serio1
serio: i8042 AUX port at 0x60,0x64 irq 12
input: AT Translated Set 2 keyboard on isa0060/serio0
serio: i8042 KBD port at 0x60,0x64 irq 1
I2O Core - (C) Copyright 1999 Red Hat Software
I2O: Event thread created as pid 16
i2o: Checking for PCI I2O controllers...
I2O configuration manager v 0.04.
(C) Copyright 1999 Red Hat Software
i2c /dev entries driver
i2c_adapter i2c-0: nForce2 SMBus adapter at 0x5000
i2c_adapter i2c-1: nForce2 SMBus adapter at 0x5100
ieee1394: Host added: ID:BUS[0-00:1023] GUID[000000508df0fbe3]
hub 2-0:1.0: new USB device on port 1, assigned address 2
Advanced Linux Sound Architecture Driver Version 0.9.7 (Thu Sep 25
19:16:36 2003 UTC).
request_module: failed /sbin/modprobe -- snd-card-0. error = -16
PCI: Setting latency timer of device 0000:00:06.0 to 64
drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 2 if 0
alt 1 proto 2 vid 0x03F0 pid 0x1004
intel8x0_measure_ac97_clock: measured 50024 usecs
intel8x0: clocking to 47391
ALSA device list:
#0: NVidia nForce2 at 0xcc081000, irq 5
NET: Registered protocol family 2
IP: routing cache hash table of 8192 buckets, 64Kbytes
TCP: Hash tables configured (established 262144 bind 65536)
NET: Registered protocol family 1
NET: Registered protocol family 17
ACPI: (supports S0 S3 S4 S5)
UDF-fs DEBUG fs/udf/lowlevel.c:65:udf_get_last_session:
CDROMMULTISESSION not supported: rc=-22
UDF-fs DEBUG fs/udf/super.c:1544:udf_fill_super: Multi-session=0
UDF-fs DEBUG fs/udf/super.c:532:udf_vrs: Starting at sector 16 (2048
byte sectors)
UDF-fs: No VRS found
XFS mounting filesystem hde6
Ending clean XFS mount for filesystem: hde6
VFS: Mounted root (xfs filesystem) readonly.
Mounted devfs on /dev
Freeing unused kernel memory: 160k freed
nvnet: module license 'NVIDIA' taints kernel.
PCI: Setting latency timer of device 0000:00:04.0 to 64
nvnet: selecting duplex setting as auto duplex mode.
nvnet: selecting speed settings as auto-negotiation.
nvnet: Optimizing driver for CPU
NTFS volume version 3.1.
NTFS volume version 3.1.
nvidia: no version magic, tainting kernel.
nvidia: module license 'NVIDIA' taints kernel.
0: nvidia: loading NVIDIA Linux x86 nvidia.o Kernel Module 1.0-4496
Wed Jul 16 19:03:09 PDT 2003
atkbd.c: Unknown key released (translated set 2, code 0x7a on
isa0060/serio0).
atkbd.c: Unknown key released (translated set 2, code 0x7a on
isa0060/serio0).
Prakash
Prakash K. Cheemplavam wrote:
>>
>> After sending out multiple patches I should have been more clear. Just
>> to avoid confusion:
>>
>> * the init_cpu_khz patch goes along side Thomas' patch.
>> * the more experimental sched_clock() -> monotonic_clock() patch I just
>> sent out for testing replaces Thomas' patch.
>
>
>
> I now tried the second one and it seems to work, tough I am not sure
> whether the performance is as good as APCI timer deavt. It seems that
> now CPU Hz is not shown anymore. Have a look at my dmesg:
>
>
> Linux version 2.6.0-test9-love3 (root@tachyon) (gcc-Version 3.3.2
> 20031022 (Gentoo Linux 3.3.2-r2, propolice)) #16 Tue Nov 18 13:54:04 CET
> 2003
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
> BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
> BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 000000003fff0000 (usable)
> BIOS-e820: 000000003fff0000 - 000000003fff3000 (ACPI NVS)
> BIOS-e820: 000000003fff3000 - 0000000040000000 (ACPI data)
> BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
> BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
> BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
> 127MB HIGHMEM available.
> 896MB LOWMEM available.
> On node 0 totalpages: 262128
> DMA zone: 4096 pages, LIFO batch:1
> Normal zone: 225280 pages, LIFO batch:16
> HighMem zone: 32752 pages, LIFO batch:7
> DMI 2.2 present.
> ACPI: RSDP (v000 Nvidia ) @ 0x000f6b60
> ACPI: RSDT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x3fff3000
> ACPI: FADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x3fff3040
> ACPI: MADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x3fff79c0
> ACPI: DSDT (v001 NVIDIA AWRDACPI 0x00001000 MSFT 0x0100000d) @ 0x00000000
> ACPI: PM-Timer IO Port: 0x4008
> Building zonelist for node : 0
> Kernel command line: root=/dev/hde6 hdg=none vga=0x51A
> video=vesa:mtrr,ywrap elevator=cfq
> ide_setup: hdg=none
> current: c0499a60
> current->thread_info: c0528000
> Initializing CPU#0
> PID hash table entries: 4096 (order 12: 32768 bytes)
> Using <NULL> for high-res timesource
[snip]
So I deactivated the PM timer again and my computer is much faster
again. Haven prime in the background taking 100% doesn't noticeable
affect deskop performance. But I think I know where the problem lies:
current: c0499a60
current->thread_info: c0528000
Initializing CPU#0
PID hash table entries: 4096 (order 12: 32768 bytes)
Detected 2004.698 MHz processor.
Using tsc for high-res timesource
In above dmesg you can see that nothing was used as timesource, but here
in current dmesg tsc is used. Is this normal or a bug? Need I pass a
kernel paramtere when pm timer is enbaled?
bye
Prakash
Prakash K. Cheemplavam wrote:
>>
>> After sending out multiple patches I should have been more clear. Just
>> to avoid confusion:
>>
>> * the init_cpu_khz patch goes along side Thomas' patch.
>> * the more experimental sched_clock() -> monotonic_clock() patch I just
>> sent out for testing replaces Thomas' patch.
>
>
>
>
> I now tried the second one and it seems to work, tough I am not sure
whether the performance is as good as APCI timer deavt. It seems that
now CPU Hz is not shown anymore. Have a look at my dmesg:
>
>
> Linux version 2.6.0-test9-love3 (root@tachyon) (gcc-Version 3.3.2
20031022 (Gentoo Linux 3.3.2-r2, propolice)) #16 Tue Nov 18 13:54:04 CET
2003
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
> BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
> BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 000000003fff0000 (usable)
> BIOS-e820: 000000003fff0000 - 000000003fff3000 (ACPI NVS)
> BIOS-e820: 000000003fff3000 - 0000000040000000 (ACPI data)
> BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
> BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
> BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
> 127MB HIGHMEM available.
> 896MB LOWMEM available.
> On node 0 totalpages: 262128
> DMA zone: 4096 pages, LIFO batch:1
> Normal zone: 225280 pages, LIFO batch:16
> HighMem zone: 32752 pages, LIFO batch:7
> DMI 2.2 present.
> ACPI: RSDP (v000 Nvidia ) @ 0x000f6b60
> ACPI: RSDT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x3fff3000
> ACPI: FADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x3fff3040
> ACPI: MADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x3fff79c0
> ACPI: DSDT (v001 NVIDIA AWRDACPI 0x00001000 MSFT 0x0100000d) @ 0x00000000
> ACPI: PM-Timer IO Port: 0x4008
> Building zonelist for node : 0
> Kernel command line: root=/dev/hde6 hdg=none vga=0x51A
video=vesa:mtrr,ywrap elevator=cfq
> ide_setup: hdg=none
> current: c0499a60
> current->thread_info: c0528000
> Initializing CPU#0
> PID hash table entries: 4096 (order 12: 32768 bytes)
> Using <NULL> for high-res timesource
[snip]
So I deactivated the PM timer again and my computer is much faster
again. Haven prime in the background taking 100% doesn't noticeable
affect deskop performance. But I think I know where the problem lies:
current: c0499a60
current->thread_info: c0528000
Initializing CPU#0
PID hash table entries: 4096 (order 12: 32768 bytes)
Detected 2004.698 MHz processor.
Using tsc for high-res timesource
In above dmesg you can see that nothing was used as timesource, but here
in current dmesg tsc is used. Is this normal or a bug? Need I pass a
kernel paramtere when pm timer is enbaled?
bye
Prakash
On Tue, 2003-11-18 at 08:11, Prakash K. Cheemplavam wrote:
> Prakash K. Cheemplavam wrote:
> >>
> >> After sending out multiple patches I should have been more clear. Just
> >> to avoid confusion:
> >>
> >> * the init_cpu_khz patch goes along side Thomas' patch.
> >> * the more experimental sched_clock() -> monotonic_clock() patch I just
> >> sent out for testing replaces Thomas' patch.
> >
> >
> >
> > I now tried the second one and it seems to work, tough I am not sure
> > whether the performance is as good as APCI timer deavt. It seems that
> > now CPU Hz is not shown anymore. Have a look at my dmesg:
The init_cpu_khz patch is the one that displays the calibrated CPU
frequency. The two patches listed above address independent bugs.
> So I deactivated the PM timer again and my computer is much faster
> again. Haven prime in the background taking 100% doesn't noticeable
> affect deskop performance. But I think I know where the problem lies:
Yes, Thomas pointed out that the sched_clock->monotonic_clock patch
didn't seem to work for pmtmr. I'm looking into if the pmtmr's
montonic_clock call is doing the right thing (didn't have my laptop
yesterday).
For now Thomas' patch to switch on "use_tsc" is the best fix when using
the pmtmr.
> current: c0499a60
> current->thread_info: c0528000
> Initializing CPU#0
> PID hash table entries: 4096 (order 12: 32768 bytes)
> Detected 2004.698 MHz processor.
> Using tsc for high-res timesource
>
>
> In above dmesg you can see that nothing was used as timesource, but here
> in current dmesg tsc is used. Is this normal or a bug? Need I pass a
> kernel paramtere when pm timer is enbaled?
No, its just cosmetic. Both Thomas and I have sent out a patch that
initializes the name field in the pmtmr's timer_opts struct.
See: http://www.ussg.iu.edu/hypermail/linux/kernel/0311.1/0983.html
I appreciate the testing and feedback!
thanks,
-john
On Mon, Nov 17, 2003 at 11:36:50AM -0800, Andrew Morton wrote:
> "Ronny V. Vindenes" <[email protected]> wrote:
> >
> > > Your report has totally confused me. Are you saying that the
> > jerkiness is
> > > caused by linus.patch? Or not? Pleas try again ;)
> > >
> >
> > I've found that neither linus.patch nor
> > context-switch-accounting-fix.patch is causing the problem, but rather
> > acpi-pm-timer-fixes.patch & acpi-pm-timer.patch
> >
> > With these applied my cpu (athlon64) is detected as 0.0Mhz, bogomips
> > drops to 50% and anything cpu intensive destroys interactivity. Revert
> > them and performance is back at -mm2 level.
>
> ah hah. Thank you!
>
> Probably the interactivity problems are due to the CPU scheduler thinking
> that the CPU runs at 0Hz.
Is this in "plain" test9 as well? can't find any reference to either
bogomips or to cpu_khz in any scheduler-related code in
2.6.0-test9-bk-as-of-yesterday.
> If we can work out why the PM timer patch has
> broken the CPU clock speed detection then all should be well.
cpu_khz is done during init_tsc. The code is basically:
unsigned long eax=0, edx=1000, tsc_quotient;
tsc_quotient = calibrate_tsc();
if (tsc_quotient) {
__asm__("divl %2"
:"=a" (cpu_khz), "=d" (edx)
:"r" (tsc_quotient),
"0" (eax), "1" (edx));
}
cpu_khz is only available (so far) if the TSC or HPET time sources are used,
and not when the PIT time source is used. So the scheduler tweak should have
some sort of fall-back mechanism anyway, IMHO.
As for the bogomips question: I see different bogomips values for
tsc (~1.200)
pit (~600)
and pmtmr (~8)
on my 600 MHz PIII Coppermine.
Dominik
On Tue, 2003-11-18 at 10:56, Dominik Brodowski wrote:
> On Mon, Nov 17, 2003 at 11:36:50AM -0800, Andrew Morton wrote:
> >
> > Probably the interactivity problems are due to the CPU scheduler thinking
> > that the CPU runs at 0Hz.
>
> Is this in "plain" test9 as well? can't find any reference to either
> bogomips or to cpu_khz in any scheduler-related code in
> 2.6.0-test9-bk-as-of-yesterday.
Well, in smp_tune_scheduling() we initialize some scheduler tunables
based on cpu_khz, but in those cases we have safe fallbacks. cpu_khz not
being initialized is a somewhat minor issue.
The big issue is sched_clock() was written to only support the TSC (and
to fall back to jiffies if cpu_has_tsc was false or we were using a
CONFIG_NUMA compiled kernel).
The problem is however that it uses functions from the TSC timesource to
convert cycles to nsecs. Those functions do not work unless the TSC is
being used as a timesource. That is why the ACPI PM and PIT were having
problems (likely cyclone as well).
Thomas' patch to only use the TSC if the TSC timesource is being used
fixes the issue. I'm playing with a patch that may help systems using
other time sources, but needs more testing.
> > If we can work out why the PM timer patch has
> > broken the CPU clock speed detection then all should be well.
>
> cpu_khz is done during init_tsc. The code is basically:
>
> unsigned long eax=0, edx=1000, tsc_quotient;
> tsc_quotient = calibrate_tsc();
> if (tsc_quotient) {
> __asm__("divl %2"
> :"=a" (cpu_khz), "=d" (edx)
> :"r" (tsc_quotient),
> "0" (eax), "1" (edx));
> }
>
> cpu_khz is only available (so far) if the TSC or HPET time sources are used,
> and not when the PIT time source is used. So the scheduler tweak should have
> some sort of fall-back mechanism anyway, IMHO.
The Cyclone timesource also initializes cpu_khz, and I sent out a patch
that made it share the initialization code w/ the ACPI PM time source.
See:
http://www.ussg.iu.edu/hypermail/linux/kernel/0311.2/0250.html
But you're correct, there are proper fallbacks for the PIT case where
cpu_khz isn't calibrated.
> As for the bogomips question: I see different bogomips values for
> tsc (~1.200)
> pit (~600)
> and pmtmr (~8)
> on my 600 MHz PIII Coppermine.
BogoMIPS is just based on loops_per_jiffy, which is calculated in
calibrate_delay(). Its name is deceiving and the output is just
cosmetic. Probably should be changed, but its historical, so I'm
hesitant.
However, the both the pit and pmtmr should be using a very similar loop
delay function which should result in the same BogoMIPS value. I'll look
into it.
thanks
-john
On Mon, 2003-11-17 at 15:46, Thomas Schlichter wrote:
> Well, but the sched_clock() -> monotonic_clock() patch seems to have a
> problem...
> First, everything works smoothly if the PIT or the TSC clock are selected. (It
> seems I cannot test the HPET timer due to missing hardware support)
>
> But when booting with the PMTMR clock selected, my Interactivity test fails
> again. :-( Maybe there is a problem in the PMTMR's monotonic clock part...?!
Good call! I was mis-adding in conversion to nanoseconds. The patch
below should fix it (Andrew, feel free to ignore this, I'll sync up all
the acpi-pm changes with you later).
Although I'm finding that the sched_clock->monotonic_clock patch doesn't
look like a win. With that patch sched_clock takes ~400-700 cycles using
clock=pmtmr. With your "fix-sched_clock.diff" patch its less then 40
cycles.
While better accuracy is nice, I can't imagine the 10-20x cost of
sched_clock is worth it. So I think your fix is the best solution.
thanks
-john
diff -Nru a/arch/i386/kernel/timers/timer_pm.c b/arch/i386/kernel/timers/timer_pm.c
--- a/arch/i386/kernel/timers/timer_pm.c Tue Nov 18 14:17:27 2003
+++ b/arch/i386/kernel/timers/timer_pm.c Tue Nov 18 14:17:27 2003
@@ -149,8 +149,8 @@
/* convert to nanoseconds */
- ret = base + ((this_offset - last_offset) & ACPI_PM_MASK);
- ret = cyc2us(ret)*1000;
+ ret = ((this_offset - last_offset) & ACPI_PM_MASK);
+ ret = base + (cyc2us(ret)*1000);
return ret;
}
On Tuesday 18 November 2003 23:59, john stultz wrote:
> On Mon, 2003-11-17 at 15:46, Thomas Schlichter wrote:
> > But when booting with the PMTMR clock selected, my Interactivity test
> > fails again. :-( Maybe there is a problem in the PMTMR's monotonic clock
> > part...?!
>
> Good call! I was mis-adding in conversion to nanoseconds. The patch
> below should fix it (Andrew, feel free to ignore this, I'll sync up all
> the acpi-pm changes with you later).
Well, your patch was the correct direction, but it did not completely reach
the target... :-( The 'monotonic_base' variable in the PMTMR stores its value
in microseconds. So the 'base' value has to be convertet to nanoseconds,
too...
A patch that corrects that is attached...
(Btw. another solution would be to store all the values in nanoseconds by
replacing the cyc2us function with a cyc2ns function...)
> Although I'm finding that the sched_clock->monotonic_clock patch doesn't
> look like a win. With that patch sched_clock takes ~400-700 cycles using
> clock=pmtmr. With your "fix-sched_clock.diff" patch its less then 40
> cycles.
>
> While better accuracy is nice, I can't imagine the 10-20x cost of
> sched_clock is worth it. So I think your fix is the best solution.
I think you are right, but the sched_clock->monotonic_clock patch helped us
finding the problems in the monotonic_clock_pmtmr() function... ;-)
> thanks
> -john
np ;-)
Thomas