linux-kernel - Re: [GIT PULL] arm64 updates for 4.4

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, 4 Nov 2015 14:55:01 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Catalin Marinas <catalin.marinas@....com>
Cc:	Will Deacon <will.deacon@....com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] arm64 updates for 4.4

On Wed, Nov 4, 2015 at 10:25 AM, Catalin Marinas
<catalin.marinas@....com> wrote:
>
> - Support for 16KB pages, with the additional bonus of a 36-bit VA
>   space, though the latter only depending on EXPERT

So I told the ppc people this many years ago, and I guess I'll tell
you guys too: 16kB pages are not actually useful, and anybody who
thinks they are have not actually done the math.

It ends up being a horrible waste of memory for things like the page
cache, to the point where all the arguments for it ("it allows us to
manage lots of memory more cheaply") are pure and utter BS, because
you effectively lose half of that memory to fragmentation in pretty
much all normal loads.

It's good for single-process loads - if you do a lot of big fortran
jobs, or a lot of big database loads, and nothing else, you're fine.
Or if you are an embedded OS and only haev one particular load you
worry about.

But it is really really nasty for any general-purpose stuff, and when
your hardware people tell you that it's a great way to make your TLB's
more effective, tell them back that they are incompetent morons, and
that they should just make their TLB's better.

Because they are.

To make them understand the problem, compare it to having a 256-byte
cacheline. They might understand it then, because you're talking about
things that they almost certainly *also* wanted to do, but did the
numbers on, and realized it was bad.

And on the other hand, if they go "Hmm. 256-byte cache lines? We
should do that too", then you know they are not worth your time, and
you can quietly tell your bosses that they should up the medication in
the watercooler in the hw lab.

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