linux-kernel - Re: [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 for Android: free password hash cracker in your pocket

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

Message-ID: <482B0363.6080700@firstfloor.org>
Date:	Wed, 14 May 2008 17:21:07 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Arjan van de Ven <arjan@...radead.org>
CC:	Vegard Nossum <vegard.nossum@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andreas Herrmann <andreas.herrmann3@....com>,
	caglar@...dus.org.tr, Valdis.Kletnieks@...edu,
	Matt Mackall <mpm@...enic.com>, linux-kernel@...r.kernel.org,
	lenb@...nel.org
Subject: Re: [BISECTED] Lots of "rescheduling IPIs" in powertop

Arjan van de Ven wrote:
> On Wed, 14 May 2008 08:58:05 +0200
>>> If the bios says mwait is usable, we need to use it with the values
>>> IT gives us.
>> At least to my knowledge the ACPI FADT just says what C states are
>> available, not if they are implemented with MWAIT or using IO ports.
> 
> _CST does; which is what the mwait C-state selection code uses.
> 
> (and we've seen quirky systems where C1 mwait didn't work, SMM did
> something wrong or something,

What do you mean with didn't work? And they did not report it in CPUID?
And are they wide spread? I haven't heard of any such problems before.

Even the P4 problem is not really that serious btw.

 because the other OS doesn't seem to use
> it for that, so making it the default is not really an option)

But it has been default for practically forever.   It is strange
if you declare Linux default behavior for years suddenly as "not really
an option"

I think it's a sane default. And MWAIT is a valuable optimization.

I don't think we should stop sanely architected interfaces on the first
BIOS quirk someone reports. I'm sure for nearly every feature there's
some broken BIOS out there that gets it wrong somehow. If we did this in
general soon we couldn't use anything.

-Andi

--
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/