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: <98eb5fef-8bf2-4d9d-b1a0-ef8d3c2c6ab7@arm.com>
Date: Mon, 15 Jul 2024 17:17:28 +0100
From: Ryan Roberts <ryan.roberts@....com>
To: David Hildenbrand <david@...hat.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/2024 17:13, David Hildenbrand wrote:
> 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.

OK got it. In that case:

Reviewed-by: Ryan Roberts <ryan.roberts@....com>

> 
> Thanks Gavin!
> 
> Acked-by: David Hildenbrand <david@...hat.com>
>