linux-kernel - Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

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]

Date:	Wed, 10 Jun 2015 11:08:13 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Mel Gorman <mgorman@...e.de>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Rik van Riel <riel@...hat.com>,
	Hugh Dickins <hughd@...gle.com>,
	Minchan Kim <minchan@...nel.org>,
	Dave Hansen <dave.hansen@...el.com>,
	Andi Kleen <andi@...stfloor.org>,
	H Peter Anvin <hpa@...or.com>, Linux-MM <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 0/3] TLB flush multiple pages per IPI v5

* Ingo Molnar <mingo@...nel.org> wrote:

> Stop this crap.
> 
> I made a really clear and unambiguous chain of arguments:
> 
>  - I'm unconvinced about the benefits of INVLPG in general, and your patches adds
>    a whole new bunch of them. [...]

... and note that your claim that 'we were doing them before, this is just an 
equivalent transformation' is utter bullsh*t technically: what we were doing 
previously was a hideously expensive IPI combined with an INVLPG.

The behavior was dominated by the huge overhead of the remote flushing IPI, which 
does not prove or disprove either your or my opinion!

Preserving that old INVLPG logic without measuring its benefits _again_ would be 
cargo cult programming.

So I think this should be measured, and I don't mind worst-case TLB trashing 
measurements, which would be relatively straightforward to construct and the 
results should be unambiguous.

The batching limit (which you set to 32) should then be tuned by comparing it to a 
working full-flushing batching logic, not by comparing it to the previous single 
IPI per single flush approach!

... and if the benefits of a complex algorithm are not measurable and if there are 
doubts about the cost/benefit tradeoff then frankly it should not exist in the 
kernel in the first place. It's not like the Linux TLB flushing code is too boring 
due to overwhelming simplicity.

and yes, it's my job as a maintainer to request measurements justifying complexity 
and your ad hominem attacks against me are disgusting - you should know better.

Thanks,

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