Re: [PATCH 1/4] arch: consolidate existing CONFIG_PAGE_SIZE_*KB definitions

Christophe Leroy <[email protected]>
Newsgroups gmane.linux.uml.devel,gmane.linux.kernel,gmane.linux.ports.alpha,gmane.linux.kernel.arc,gmane.linux.ports.arm.kernel,gmane.linux.ports.hexagon,gmane.linux.ports.mips,gmane.linux.ports.parisc,gmane.linux.ports.ppc64.devel,gmane.linux.ports.riscv,gmane.linux.ports.sh.devel,gmane.linux.ports.sparc
Message-ID <[email protected]>

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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.