Message-ID: <7ca333ba-f9bc-4f78-8f5b-1035ca91c2d5@redhat.com>
Date: Mon, 28 Oct 2024 10:48:44 +0100
From: David Hildenbrand <david@...hat.com>
To: Daniel Gomez <d@...ces.com>, Baolin Wang <baolin.wang@...ux.alibaba.com>,
 Daniel Gomez <da.gomez@...sung.com>,
 "Kirill A. Shutemov" <kirill@...temov.name>
Cc: Matthew Wilcox <willy@...radead.org>, akpm@...ux-foundation.org,
 hughd@...gle.com, wangkefeng.wang@...wei.com, 21cnbao@...il.com,
 ryan.roberts@....com, ioworker0@...il.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 25.10.24 22:21, David Hildenbrand wrote:
> Sorry for the late reply!
> 
>>>>>> IMHO, as I discussed with Kirill, we still need maintain compatibility
>>>>>> with the 'huge=' mount option. This means that if 'huge=never' is set
>>>>>> for tmpfs, huge page allocation will still be prohibited (which can
>>>>>> address Hugh's request?). However, if 'huge=' is not set, we can
>>>>>> allocate large folios based on the write size.
>>
>> So, in order to make tmpfs behave like other filesystems, we need to
>> allocate large folios by default. Not setting 'huge=' is the same as
>> setting it to 'huge=never' as per documentation. But 'huge=' is meant to
>> control THP, not large folios, so it should not have a conflict here, or
>> else, what case are you thinking?
> 
> I think we really have to move away from "huge/thp == PMD", that's a
> historical artifact. Everything else will simply be inconsistent and
> confusing in the future -- and I don't see any real need for that. For
> anonymous memory and anon shmem we managed the transition. (there is a
> longer writeup from me about this topic, so I won't go into detail).
> 
> 
> I think I raised this in the past, but tmpfs/shmem is just like any
> other file system .. except it sometimes really isn't and behaves much
> more like (swappable) anonymous memory. (or mlocked files)
> 
> There are many systems out there that run without swap enabled, or with
> extremely minimal swap (IIRC until recently kubernetes was completely
> incompatible with swapping). Swap can even be disabled today for shmem
> using a mount option.
> 
> That's a big difference to all other file systems where you are
> guaranteed to have backend storage where you can simply evict under
> memory pressure (might temporarily fail, of course).
> 
> I *think* that's the reason why we have the "huge=" parameter that also
> controls the THP allocations during page faults (IOW possible memory
> over-allocation). Maybe also because it was a new feature, and we only
> had a single THP size.
> 
> There is, of course also the "fallocate() might not free up memory if
> there is an unexpected reference on the page because splitting it will
> fail" problem, that even exists when not over-allocating memory in the
> first place ...
> 
> 
> So ...I don't think tmpfs behaves like other file system in some cases.
> And I don't think ignoring these points is a good idea.
> 
> Fortunately I don't maintain that code :)
> 
> 
> If we don't want to go with the shmem_enabled toggles, we should
> probably still extend the documentation to cover "all THP sizes", like
> we did elsewhere.
> 
> huge=never: no THPs of any size
> huge=always: THPs of any size (fault/write/etc)
> huge=fadvise: like "always" but only with fadvise/madvise
> huge=within_size: like "fadvise" but respect i_size

Thinking some more about that over the weekend, this is likely the way 
to go, paired with conditionally changing the default to 
always/within_size. I suggest a kconfig option for that.

That should probably do as a first shot; I assume people will want more 
control over which size to use, especially during page faults, but that 
can likely be added later.

-- 
Cheers,

David / dhildenb

Powered by blists - more mailing lists