Re: Terrible interactivity with 2.6.0-t9-mm3

[Thomas Schlichter <schlicht@uni-mannheim.de>]

[-- Attachment #1.1: Type: text/plain, Size: 2254 bytes --]

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

[-- Attachment #1.2: fix-sched_clock.diff --]
[-- Type: text/x-diff, Size: 703 bytes --]

--- 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);
 

[-- Attachment #1.3: pmtmr-name-diff --]
[-- Type: text/x-diff, Size: 436 bytes --]

--- 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 #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]