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

[Christophe Leroy <christophe.leroy@csgroup.eu>]

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.
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc