linux-kernel - Re: [PATCH] microblaze: Remove noMMU code

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] [day] [month] [year] [list]

Date:   Wed, 25 Nov 2020 14:57:53 +0100
From:   Arnd Bergmann <arnd@...nel.org>
To:     Michal Simek <michal.simek@...inx.com>
Cc:     Mike Rapoport <rppt@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Michal Simek <monstr@...str.eu>, git <git@...inx.com>,
        Arnd Bergmann <arnd@...db.de>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Anshuman Khandual <anshuman.khandual@....com>,
        Arvind Sankar <nivedita@...m.mit.edu>,
        Baoquan He <bhe@...hat.com>,
        Christian Brauner <christian.brauner@...ntu.com>,
        Dmitry Safonov <0x7f454c46@...il.com>,
        Eric Biggers <ebiggers@...gle.com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        "Gustavo A. R. Silva" <gustavoars@...nel.org>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        Ira Weiny <ira.weiny@...el.com>, Jens Axboe <axboe@...nel.dk>,
        Joe Perches <joe@...ches.com>,
        Kees Cook <keescook@...omium.org>,
        Manish Narani <manish.narani@...inx.com>,
        Oleg Nesterov <oleg@...hat.com>,
        Pekka Enberg <penberg@...nel.org>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        Rob Herring <robh@...nel.org>,
        Robin Murphy <robin.murphy@....com>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Stafford Horne <shorne@...il.com>,
        Stefan Asserhall <stefan.asserhall@...inx.com>,
        "Steven Rostedt (VMware)" <rostedt@...dmis.org>,
        Vlastimil Babka <vbabka@...e.cz>
Subject: Re: [PATCH] microblaze: Remove noMMU code

On Wed, Nov 25, 2020 at 2:01 PM Michal Simek <michal.simek@...inx.com> wrote:
> On 25. 11. 20 13:57, Arnd Bergmann wrote:
> > On Wed, Nov 25, 2020 at 1:14 PM Michal Simek <michal.simek@...inx.com> wrote:
> >>
> >> And second part. I know I removed that Kconfig macros for it but maybe
> >> good to talk about what needs to change to support different page size
> >> for systems with MMU.
> >
> > I would recommend just leaving it hardwired to 4K. The benefits of larger
> > pages are rather questionable, especially on systems without tons of
> > RAM, and it's an endless source of problems.
> >
> > The commit that added the option, ba9c4f88d747 ("microblaze: Allow
> > PAGE_SIZE configuration"), was rather nebulous with "can improve
> > performance on some workloads".
> >
> > On PowerPC, the benefits of larger pages are mainly for the hashed
> > page table code, which I don't think exists anywhere else.
>
> Is there any standard benchmark to see if there is really any benefit?
> Exchanging tbl is quite expensive operation that's why there could be
> good improvement.
>
> But not a problem to remove it for now and get it back when this is
> properly tested.

The problem is that some benchmarks benefit hugely from larger
pages because of running into fewer TLB misses, but others
suffer even more because you end up using much more memory
to run the same workload.

IIRC I calculated that keeping the kernel source tree in the page
cache needs 10x as much physical memory on a 64K page
size compared to 4K pages because each file is stored in
a multiple of a full page. It's less of a problem if you have
terabytes of RAM, but on 32-bit systems you rarely do.

A more useful way to reduce TLB misses would be to support
huge pages. I see that the CPU can support 256KB, 1MB, 4MB
and 16 MB pages as well, so those would be good to have as
huge page sizes.

Some architectures actually support mixing huge page sizes
nowadays, but the easiest change would be to pick one of them.

      Arnd