Re: Terrible interactivity with 2.6.0-t9-mm3

[Dominik Brodowski <linux@brodo.de>]

On Mon, Nov 17, 2003 at 11:36:50AM -0800, Andrew Morton wrote:
> "Ronny V. Vindenes" <s864@ii.uib.no> 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