Re: Terrible interactivity with 2.6.0-t9-mm3

From: Thomas Schlichter
Date: Mon Nov 17 2003 - 14:47:38 EST


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
--- linux-2.6.0-test9-mm3/arch/i386/kernel/timers/timer_tsc.c Sat Nov 15 18:09:24 2003
+++ linux-2.6.0-test9-mm3_patched/arch/i386/kernel/timers/timer_tsc.c Mon Nov 17 19:27:36 2003
@@ -32,7 +32,7 @@ int tsc_disable __initdata = 0;
extern spinlock_t i8253_lock;
extern volatile unsigned long jiffies;

-static int use_tsc;
+static int use_tsc = 0;
/* Number of usecs that the last interrupt was delayed */
static int delay_at_last_interrupt;

@@ -139,7 +139,7 @@ unsigned long long sched_clock(void)
* synchronized across all CPUs.
*/
#ifndef CONFIG_NUMA
- if (unlikely(!cpu_has_tsc))
+ if (!use_tsc)
#endif
return (unsigned long long)jiffies * (1000000000 / HZ);

--- linux-2.6.0-test9-mm3/arch/i386/kernel/timers/timer_pm.c Sat Nov 15 18:09:24 2003
+++ linux-2.6.0-test9-mm3_patched/arch/i386/kernel/timers/timer_pm.c Mon Nov 17 19:29:30 2003
@@ -185,6 +185,7 @@ static unsigned long get_offset_pmtmr(vo

/* acpi timer_opts struct */
struct timer_opts timer_pmtmr = {
+ .name = "pmtmr",
.init = init_pmtmr,
.mark_offset = mark_offset_pmtmr,
.get_offset = get_offset_pmtmr,

Attachment: pgp00001.pgp
Description: signature