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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2c3a5213-ca64-48fb-845a-78aae3e8f15f@redhat.com>
Date: Mon, 15 Jul 2024 18:13:21 +0200
From: David Hildenbrand <david@...hat.com>
To: Ryan Roberts <ryan.roberts@....com>, Gavin Shan <gshan@...hat.com>,
 linux-mm@...ck.org
Cc: linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
 willy@...radead.org, baohua@...nel.org, peterx@...hat.com, ziy@...dia.com,
 william.kucharski@...cle.com, baolin.wang@...ux.alibaba.com,
 ddutile@...hat.com, shan.gavin@...il.com
Subject: Re: [PATCH v2] mm/huge_memory: Avoid PMD-size page cache if needed

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@...hat.com>

-- 
Cheers,

David / dhildenb