linux-kernel - Re: [Bug #10710] [BISECTED] Lots of "rescheduling IPIs" in powertop

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.1.10.0805182017070.18798@apollo.tec.linutronix.de>
Date:	Sun, 18 May 2008 21:27:28 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Andi Kleen <andi@...stfloor.org>
cc:	Vegard Nossum <vegard.nossum@...il.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Andreas Herrmann <andreas.herrmann3@....com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [Bug #10710] [BISECTED] Lots of "rescheduling IPIs" in
 powertop

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/