[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f1aa025b-b3f2-4667-b628-3f0f17f5fe76@linux.alibaba.com>
Date: Wed, 23 Oct 2024 17:25:42 +0800
From: Baolin Wang <baolin.wang@...ux.alibaba.com>
To: "Kirill A. Shutemov" <kirill@...temov.name>
Cc: Matthew Wilcox <willy@...radead.org>, akpm@...ux-foundation.org,
hughd@...gle.com, david@...hat.com, wangkefeng.wang@...wei.com,
21cnbao@...il.com, ryan.roberts@....com, ioworker0@...il.com,
da.gomez@...sung.com, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
"Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>
Subject: Re: [RFC PATCH v3 0/4] Support large folios for tmpfs
On 2024/10/22 18:06, Kirill A. Shutemov wrote:
> On Tue, Oct 22, 2024 at 11:34:14AM +0800, Baolin Wang wrote:
>> IIUC, most file systems use method similar to iomap buffered IO (see
>> iomap_get_folio()) to allocate huge pages. What I mean is that, it would be
>> better to have a real use case to add a hint for allocating THP (other than
>> tmpfs).
>
> I would be nice to hear from folks who works with production what the
> actual needs are.
>
> But I find asymmetry between MADV_ hints and FADV_ hints wrt huge pages
> not justified. I think it would be easy to find use-cases for
> FADV_HUGEPAGE/FADV_NOHUGEPAGE.
>
> Furthermore I think it would be useful to have some kind of mechanism to
> make these hints persistent: any open of a file would have these hints set
> by default based on inode metadata on backing storage. Although, I am not
> sure what the right way to archive that. xattrs?
May be can re-use mapping_set_folio_order_range()?
Powered by blists - more mailing lists