Skip to contentSkip to conversation

io apic + tsc = slowdown (bugreport + possible fix)

DISCUSSION Frederic Krueger 3 participants 5 messages Jun 28, 2004 – Jun 29, 2004

lore
Share & tools
lore
#0 lore raw

Hi,

just wanted to point out the patch I imported from an older version of the 2.6.x kernel (not done by me at all ;-)).
It's basically causing the system to a near zero slowdown after one hour of uptime. And the reason for it must be the io_apic irq0 handling with TSC enabled systems (seems to show up on ibm pre-built boxes more often than on others though). Funnily pressing any keys _all the time_ works around for this for the time a key is pressed ;)

The bug report entry contains a patch for arch/i386/kernel/io_apic.c which fixed it for me.
Maybe this should make it into the cvs tree since it's a _really_ annoying bug, basically rendering the computer unusable if present.

The link to the bug report with more detailed information can be found here:
http://bugme.osdl.org/show_bug.cgi?id=2964

Thanks for checking and considering :-)

Bye,
Frederic

#1 lore raw
Quoted 8 lines · Frederic Krueger

just wanted to point out the patch I imported from an older version of the 2.6.x kernel (not done by me at all ;-)).
It's basically causing the system to a near zero slowdown after one hour of uptime. And the reason for it must be the io_apic irq0 handling with TSC enabled systems (seems to show up on ibm pre-built boxes more often than on others though).
Funnily pressing any keys _all the time_ works around for this for the time a key is pressed ;)

I duped the bug to 2544. I've got the BIOS folks looking at this issue on the x305 for the proper fix.

Looking closer at the proposed workaround by Maciej posted here:
http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-04/3174.html

Why exactly are we using cpu_has_tsc to switch this? I'm not sure I'm following how this is TSC dependent. Additionally the comment change looks to be from the 2.4 era.

Maciej, could you further explain?

thanks
-john

#2 lore raw
Quoted 6 lines · john stultz

Looking closer at the proposed workaround by Maciej posted here:
http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-04/3174.html

Why exactly are we using cpu_has_tsc to switch this? I'm not sure I'm following how this is TSC dependent. Additionally the comment change looks to be from the 2.4 era.

One of the two users of timer_ack is do_slow_gettimeoffset(). When the
TSC is selected for use as a high-precision timer do_fast_gettimeoffset() is used instead.

Please folks do read the sources sometimes -- I've been repeatedly
clarifying these bits while they are all documented in the sources, sigh...

Maciej

#3 lore raw
Quoted 9 lines · Maciej W. Rozycki
Quoted 6 lines · john stultz

Looking closer at the proposed workaround by Maciej posted here:
http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-04/3174.html

Why exactly are we using cpu_has_tsc to switch this? I'm not sure I'm following how this is TSC dependent. Additionally the comment change looks to be from the 2.4 era.

Quoted 7 lines

One of the two users of timer_ack is do_slow_gettimeoffset(). When the
TSC is selected for use as a high-precision timer do_fast_gettimeoffset() is used instead.

Please folks do read the sources sometimes -- I've been repeatedly
clarifying these bits while they are all documented in the sources, sigh...

Whoops, sorry, I had the impression the patch was targeted against 2.6, where there is no do_slow_gettimeoffset() and the only user of timer_ack is in do_timer_interrupt().

So am I incorrect that the TSC bits can be dropped for the 2.6 version of the patch?

thanks
-john

#4 lore raw
Quoted 5 lines · john stultz
Quoted 3 lines

Please folks do read the sources sometimes -- I've been repeatedly
clarifying these bits while they are all documented in the sources, sigh...

Whoops, sorry, I had the impression the patch was targeted against 2.6,

It works the same way for both series.

Quoted 2 lines

where there is no do_slow_gettimeoffset() and the only user of timer_ack is in do_timer_interrupt().

A quick search reveals the bits were moved to do_timer_overflow() in
include/asm-i386/mach-default/do_timer.h which is used by arch/i386/kernel/timers/timer_pit.c -- I suppose the comment in arch/i386/kernel/time.c needs an update then.

Quoted 2 lines

So am I incorrect that the TSC bits can be dropped for the 2.6 version of the patch?

You are, sorry.

Maciej