linux-kernel - Re: [RFC PATCH v3 0/4] Support large folios for tmpfs

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: <6457b1fa-9afd-4552-ae5b-3a0379bcc3e5@huawei.com>
Date: Wed, 16 Oct 2024 21:45:24 +0800
From: Kefeng Wang <wangkefeng.wang@...wei.com>
To: Baolin Wang <baolin.wang@...ux.alibaba.com>, <akpm@...ux-foundation.org>,
	<hughd@...gle.com>
CC: <willy@...radead.org>, <david@...hat.com>, <21cnbao@...il.com>,
	<ryan.roberts@....com>, <ioworker0@...il.com>, <da.gomez@...sung.com>,
	<linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v3 0/4] Support large folios for tmpfs



On 2024/10/16 17:29, Baolin Wang wrote:
> 
> 
> On 2024/10/16 15:49, Kefeng Wang wrote:
>>
>>
>> On 2024/10/10 17:58, Baolin Wang wrote:
>>> Hi,
>>>
>>> This RFC patch series attempts to support large folios for tmpfs.
>>>
>>> Considering that tmpfs already has the 'huge=' option to control the THP
>>> allocation, it is necessary to maintain compatibility with the 'huge='
>>> option, as well as considering the 'deny' and 'force' option controlled
>>> by '/sys/kernel/mm/transparent_hugepage/shmem_enabled'.
>>>
>>> Add a new huge option 'write_size' to support large folio allocation 
>>> based
>>> on the write size for tmpfs write and fallocate paths. So the huge pages
>>> allocation strategy for tmpfs is that, if the 'huge=' option
>>> (huge=always/within_size/advise) is enabled or the 'shmem_enabled' 
>>> option
>>> is 'force', it need just allow PMD sized THP to keep backward 
>>> compatibility
>>> for tmpfs. While 'huge=' option is disabled (huge=never) or the 
>>> 'shmem_enabled'
>>> option is 'deny', it will still disable any large folio allocations. 
>>> Only
>>> when the 'huge=' option is 'write_size', it will allow allocating large
>>> folios based on the write size.
>>>
>>> And I think the 'huge=write_size' option should be the default behavior
>>> for tmpfs in future.
>>
>> Could we avoid new huge= option for tmpfs, maybe support other orders
>> for both read/write/fallocate if mount with huge?
> 
> Um, I am afraid not, as that would break the 'huge=' compatibility. That 
> is to say, users still want PMD-sized huge pages if 'huge=always'.

Yes, compatibility maybe an issue, but only write/fallocate side support
large folio is a little strange, maybe a new mode to support both read/
write/fallocate?