Re: [PATCH v2] mm/huge_memory: Avoid PMD-size page cache if needed

[David Hildenbrand <david@redhat.com>]

On 15.07.24 12:41, Ryan Roberts wrote:
> [...]
> 
>> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
>> index 2aa986a5cd1b..c73ad77fa33d 100644
>> --- a/include/linux/huge_mm.h
>> +++ b/include/linux/huge_mm.h
>> @@ -72,14 +72,20 @@ extern struct kobj_attribute shmem_enabled_attr;
>>   #define THP_ORDERS_ALL_ANON	((BIT(PMD_ORDER + 1) - 1) & ~(BIT(0) | BIT(1)))
>>   
>>   /*
>> - * Mask of all large folio orders supported for file THP.
>> + * Mask of all large folio orders supported for file THP. Folios in a DAX
>> + * file is never split and the MAX_PAGECACHE_ORDER limit does not apply to
>> + * it.
>>    */
>> -#define THP_ORDERS_ALL_FILE	(BIT(PMD_ORDER) | BIT(PUD_ORDER))
>> +#define THP_ORDERS_ALL_FILE_DAX		\
>> +	(BIT(PMD_ORDER) | BIT(PUD_ORDER))
> 
> Appologies if this was already discussed, but if changing _FILE_DEFAULT to
> advertise all orders 1-MAX_PAGECACHE_ORDER, shouldn't we also change _FILE_DAX
> to advertise all orders 1-PUD_ORDER ? Or is DAX literally limited to PTE/PMD/PUD?

It's limited to that.

IIUC, it's simply some physical memory area that can be interpreted as 
small folios, PMD-sized folios or PUD-sized folios, and someone (fsdax?) 
makes the decision "how" it is interpreted/setup these folios.

These folios can only be mapped entirely (single PMD/PUD) or via PTEs, 
so PMD_ORDER+PUD_ORDER is correct.

Thanks Gavin!

Acked-by: David Hildenbrand <david@redhat.com>

-- 
Cheers,

David / dhildenb