Re: [RFC PATCH v4 12/16] powerpc/e500: Encode hugepage size in PTE bits

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Le 29/05/2024 à 12:09, Oscar Salvador a écrit :
> On Wed, May 29, 2024 at 09:49:48AM +0000, Christophe Leroy wrote:
>> Doesn't really matter if it's PUD or PMD at this point. On a 32 bits
>> kernel it will be all PMD while on a 64 bits kernel it is both PMD and PUD.
>>
>> At the time being (as implemented with hugepd), Linux support 4M, 16M,
>> 64M, 256M and 1G (Shifts 22, 24, 26, 28, 30)
>>
>> The hardware supports the following page sizes, and encodes them on 4
>> bits allthough it is not directly a shift. Maybe it would be better to
>> use that encoding after all:
> 
> I think so.
> 
>>
>> 0001 4 Kbytes (Shift 12)
>> 0010 16 Kbytes (Shift 14)
>> 0011 64 Kbytes (Shift 16)
>> 0100 256 Kbytes (Shift 18)
>> 0101 1 Mbyte (Shift 20)
>> 0110 4 Mbytes (Shift 22)
>> 0111 16 Mbytes (Shift 24)
>> 1000 64 Mbytes (Shift 26)
>> 1001 256 Mbytes (Shift 28)
>> 1010 1 Gbyte (e500v2 only) (Shift 30)
>> 1011 4 Gbytes (e500v2 only) (Shift 32)
> 
> You say hugehages start at 2MB (shift 21), but you say that the smallest hugepage
> Linux support is 4MB (shift 22).?
> 
> 

No I say PMD_SIZE is 2MB on e500 with 64 bits PTE and at the time being 
Linux powerpc implementation for e500 supports sizes 4M, 16M, 64M, 256M 
and 1G.

But for instead on 8xx we have 16k and 512M hugepages. Here on the e500 
we could in a follow-up patch add support to lower pagesizes for 
instance 16k, 64k, 256k and 1M. Of course all would then be cont-PTE and 
not cont-PMD




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux