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 for Android: free password hash cracker in your pocket

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

Message-ID: <007880ac-d73f-4eef-9978-a4f844338522@huawei.com>
Date: Wed, 16 Oct 2024 15:49:31 +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/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?

> 
> Any comments and suggestions are appreciated. Thanks.
> 
> Changes from RFC v2:
>   - Drop mTHP interfaces to control huge page allocation, per Matthew.
>   - Add a new helper to calculate the order, suggested by Matthew.
>   - Add a new huge=write_size option to allocate large folios based on
>     the write size.
>   - Add a new patch to update the documentation.
> 
> Changes from RFC v1:
>   - Drop patch 1.
>   - Use 'write_end' to calculate the length in shmem_allowable_huge_orders().
>   - Update shmem_mapping_size_order() per Daniel.
> 
> Baolin Wang (4):
>    mm: factor out the order calculation into a new helper
>    mm: shmem: change shmem_huge_global_enabled() to return huge order
>      bitmap
>    mm: shmem: add large folio support to the write and fallocate paths
>      for tmpfs
>    docs: tmpfs: add documention for 'write_size' huge option
> 
>   Documentation/filesystems/tmpfs.rst |   7 +-
>   include/linux/pagemap.h             |  16 ++++-
>   mm/shmem.c                          | 105 ++++++++++++++++++++--------
>   3 files changed, 94 insertions(+), 34 deletions(-)
>