Message-Id: <e49232e2-9fa9-4f83-9471-a3852b83c113@app.fastmail.com>
Date: Tue, 27 Feb 2024 16:42:43 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Christophe Leroy" <christophe.leroy@...roup.eu>,
 "Arnd Bergmann" <arnd@...nel.org>, "Thomas Gleixner" <tglx@...utronix.de>,
 "Vincenzo Frascino" <vincenzo.frascino@....com>,
 "Kees Cook" <keescook@...omium.org>,
 "Anna-Maria Gleixner" <anna-maria@...utronix.de>
Cc: "Matt Turner" <mattst88@...il.com>, "Vineet Gupta" <vgupta@...nel.org>,
 "Russell King" <linux@...linux.org.uk>,
 "Catalin Marinas" <catalin.marinas@....com>, guoren <guoren@...nel.org>,
 "Brian Cain" <bcain@...cinc.com>, "Huacai Chen" <chenhuacai@...nel.org>,
 "Geert Uytterhoeven" <geert@...ux-m68k.org>,
 "Michal Simek" <monstr@...str.eu>,
 "Thomas Bogendoerfer" <tsbogend@...ha.franken.de>,
 "Helge Deller" <deller@....de>, "Michael Ellerman" <mpe@...erman.id.au>,
 "Palmer Dabbelt" <palmer@...belt.com>,
 "John Paul Adrian Glaubitz" <glaubitz@...sik.fu-berlin.de>,
 "Andreas Larsson" <andreas@...sler.com>,
 "Richard Weinberger" <richard@....at>, "x86@...nel.org" <x86@...nel.org>,
 "Max Filippov" <jcmvbkbc@...il.com>, "Andy Lutomirski" <luto@...nel.org>,
 "Jan Kiszka" <jan.kiszka@...mens.com>,
 "Kieran Bingham" <kbingham@...nel.org>,
 "Andrew Morton" <akpm@...ux-foundation.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "linux-alpha@...r.kernel.org" <linux-alpha@...r.kernel.org>,
 "linux-snps-arc@...ts.infradead.org"
 <linux-snps-arc@...ts.infradead.org>,
 "linux-arm-kernel@...ts.infradead.org"
 <linux-arm-kernel@...ts.infradead.org>,
 "linux-csky@...r.kernel.org" <linux-csky@...r.kernel.org>,
 "linux-hexagon@...r.kernel.org" <linux-hexagon@...r.kernel.org>,
 "loongarch@...ts.linux.dev" <loongarch@...ts.linux.dev>,
 "linux-m68k@...ts.linux-m68k.org" <linux-m68k@...ts.linux-m68k.org>,
 "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
 "linux-openrisc@...r.kernel.org" <linux-openrisc@...r.kernel.org>,
 "linux-parisc@...r.kernel.org" <linux-parisc@...r.kernel.org>,
 "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
 "linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
 "linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
 "linux-sh@...r.kernel.org" <linux-sh@...r.kernel.org>,
 "sparclinux@...r.kernel.org" <sparclinux@...r.kernel.org>,
 "linux-um@...ts.infradead.org" <linux-um@...ts.infradead.org>
Subject: Re: [PATCH 1/4] arch: consolidate existing CONFIG_PAGE_SIZE_*KB definitions

On Mon, Feb 26, 2024, at 20:02, Christophe Leroy wrote:
> Le 26/02/2024 à 17:14, Arnd Bergmann a écrit :
>> From: Arnd Bergmann <arnd@...db.de>
>
> That's a nice re-factor.
>
> The only drawback I see is that we are loosing several interesting 
> arch-specific comments/help text. Don't know if there could be an easy 
> way to keep them.

This is what I have now, trying to write it as generic as
possible while still giving useful advice:

config PAGE_SIZE_4KB
        bool "4KiB pages"
        depends on HAVE_PAGE_SIZE_4KB
        help
          This option select the standard 4KiB Linux page size and the only
          available option on many architectures. Using 4KiB page size will
          minimize memory consumption and is therefore recommended for low
          memory systems.
          Some software that is written for x86 systems makes incorrect
          assumptions about the page size and only runs on 4KiB pages.

config PAGE_SIZE_8KB
        bool "8KiB pages"
        depends on HAVE_PAGE_SIZE_8KB
        help
          This option is the only supported page size on a few older
          processors, and can be slightly faster than 4KiB pages.

config PAGE_SIZE_16KB
        bool "16KiB pages"
        depends on HAVE_PAGE_SIZE_16KB
        help
          This option is usually a good compromise between memory
          consumption and performance for typical desktop and server
          workloads, often saving a level of page table lookups compared
          to 4KB pages as well as reducing TLB pressure and overhead of
          per-page operations in the kernel at the expense of a larger
          page cache.

config PAGE_SIZE_32KB
        bool "32KiB pages"
        depends on HAVE_PAGE_SIZE_32KB
          Using 32KiB page size will result in slightly higher performance
          kernel at the price of higher memory consumption compared to
          16KiB pages.  This option is available only on cnMIPS cores.
          Note that you will need a suitable Linux distribution to
          support this.

config PAGE_SIZE_64KB
        bool "64KiB pages"
        depends on HAVE_PAGE_SIZE_64KB
          Using 64KiB page size will result in slightly higher performance
          kernel at the price of much higher memory consumption compared to
          4KiB or 16KiB pages.
          This is not suitable for general-purpose workloads but the
          better performance may be worth the cost for certain types of
          supercomputing or database applications that work mostly with
          large in-memory data rather than small files.

config PAGE_SIZE_256KB
        bool "256KiB pages"
        depends on HAVE_PAGE_SIZE_256KB
        help
          256KB pages have little practical value due to their extreme
          memory usage.

Let me know if you think some of this should be adapted further.

>>   
>> +#define PAGE_SHIFT CONFIG_PAGE_SHIFT
>>   #define PAGE_SIZE  (1UL << PAGE_SHIFT)
>>   #define PAGE_MASK  (~((1 << PAGE_SHIFT) - 1))
>>   
>
> Could we move PAGE_SIZE and PAGE_MASK in a generic/core header instead 
> of having it duplicated for each arch ?

Yes, but I'm leaving this for a follow-up series, since I had
to stop somewhere and there is always room for cleanup up headers
further ;-)

      Arnd

Powered by blists - more mailing lists