Re: [Bug #10710] [BISECTED] Lots of "rescheduling IPIs" inpowertop

[Thomas Gleixner]

On Sun, 18 May 2008, Andi Kleen wrote:
> > Ingo Molnar provided the patch that solved the problem (the referenced
> > link) but he wanted to wait for Andreas Herrmann to provide an
> > additional patch that would solve some implication on AMD CPUs. So
> > this is in theory fixed, but the fix has not yet been applied anywhere
> > as far as I know.
> 
> There's a CPUID way to distingush the cases I found out now (with help
> from Venki, thanks) so it would be possible to solve it properly, but
> once even a bad Ingo patch is in it's nearly impossible to replace it
> with something better so I bail out at this point.

Andi,

stop these pointless ad hominem attacks!

When a better solution is available then it _is_ applied regardless of
the persons involved.

Right now we had the choice to wait until the CPUID solution becomes
eventually correct or just revert to the state which was working
before. There was no sign of a solution so I went back to the old
known to work state which excludes AMD family 0x10/11 from mwait.

Where is the problem ?

> [In case someone is interested it's CPUID 5 ECX bit 0 which enumerates
> if the MWAIT enumeration is there. So the correct mwait_usable() that
> would have avoided your problem would be something like (untested):
> 
> return c->cpuid_level >= 5 &&
>            ((cpuid_ecx(5) & 1) == 0 || (cpuid_edx(5) >> 4) & 0xf) > 0);
> ]

I'm interested, but I'd be even more interested in some useful pointer
to the magic bitnumbers in that check, but don't exert yourself in
providing the information, I'm going to figure it out myself.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/