Message-ID: <b737a088-c811-45eb-b143-d24e6cdf7eea@csgroup.eu>
Date: Tue, 27 Feb 2024 15:44:31 +0000
From: Christophe Leroy <christophe.leroy@...roup.eu>
To: Arnd Bergmann <arnd@...db.de>, Samuel Holland <samuel.holland@...ive.com>,
	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



Le 27/02/2024 à 16:40, Arnd Bergmann a écrit :
> On Mon, Feb 26, 2024, at 17:55, Samuel Holland wrote:
>> On 2024-02-26 10:14 AM, Arnd Bergmann wrote:
>>>   
>>> +config HAVE_PAGE_SIZE_4KB
>>> +	bool
>>> +
>>> +config HAVE_PAGE_SIZE_8KB
>>> +	bool
>>> +
>>> +config HAVE_PAGE_SIZE_16KB
>>> +	bool
>>> +
>>> +config HAVE_PAGE_SIZE_32KB
>>> +	bool
>>> +
>>> +config HAVE_PAGE_SIZE_64KB
>>> +	bool
>>> +
>>> +config HAVE_PAGE_SIZE_256KB
>>> +	bool
>>> +
>>> +choice
>>> +	prompt "MMU page size"
>>
>> Should this have some generic help text (at least a warning about
>> compatibility)?
> 
> Good point. I've added some of this now, based on the mips
> text with some generalizations for other architectures:
> 
> 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.


For 256K pages, powerpc has the following help. I think you should have 
it too:

	  The kernel will only be able to run applications that have been
	  compiled with '-zmax-page-size' set to 256K (the default is 64K) using
	  binutils later than 2.17.50.0.3, or by patching the ELF_MAXPAGESIZE
	  definition from 0x10000 to 0x40000 in older versions.

Powered by blists - more mailing lists