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.
I am still worried about adding a new kconfig option, which might
complicate the tmpfs controls further.
Why exactly?
If we are changing a default similar to
CONFIG_TRANSPARENT_HUGEPAGE_NEVER -> CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS,
it would make perfectly sense to give people building a kernel control
over that.
If we want to support this feature in a distro kernel like RHEL we'll
have to leave the default unmodified. Otherwise I see no way (excluding
downstream-only hacks) to backport this into distro kernels.
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.
I know, it puts you in a bad position because there are different
opinions floating around. But let's try to find something that is
reasonable and still acceptable. And let's hope that Hugh will voice an
opinion :D
After some discussions, I think the first step is to achieve two goals:
1) Try to make tmpfs use large folios like other file systems, that
means we should avoid adding more complex control options (per Matthew).
2) Still need maintain compatibility with the 'huge=' mount option (per
Kirill), as I also remembered we have customers who use
'huge=within_size' to allocate THPs for better performance.
Based on these considerations, my first step is to neither add a new
'huge=' option parameter nor introduce the mTHP interfaces control for
tmpfs, but rather to change the default huge allocation behavior for
tmpfs. That is to say, when 'huge=' option is not configured, we will
allow the huge folios allocation based on the write size. As a result,
the behavior of huge pages for tmpfs will change as follows:
> > no 'huge=' set: can allocate any size huge folios based on write size
> huge=never: no any size huge folios> huge=always: only PMD sized THP
allocation as before
> huge=fadvise: like "always" but only with fadvise/madvise>
huge=within_size: like "fadvise" but respect i_size
I don't like that:
(a) there is no way to explicitly enable/name that new behavior.
(b) "always" etc. are only concerned about PMDs.
So again, I suggest:
huge=never: No THPs of any size
huge=always: THPs of any size
huge=fadvise: like "always" but only with fadvise/madvise
huge=within_size: like "fadvise" but respect i_size
"huge=" default depends on a Kconfig option.
With that we:
(1) Maximize the cases where we will use large folios of any sizes
(which Willy cares about).
(2) Have a way to disable them completely (which I care about).
(3) Allow distros to keep the default unchanged.
Likely, for now we will only try allocating PMD-sized THPs during page
faults, and allocate different sizes only during write(). So the effect
for many use cases (VMs, DBs) that primarily mmap() tmpfs files will be
completely unchanged even with "huge=always".
It will get more tricky once we change that behavior as well, but that's
something to likely figure out if it is a real problem at at different
day :)
I really preferred using the sysfs toggles (as discussed with Hugh in
the meeting back then), but I can also understand why we at least want
to try making tmpfs behave more like other file systems. But I'm a bit
more careful to not ignore the cases where it really isn't like any
other file system.
If we start making PMD-sized THPs special in any non-configurable way,
then we are effectively off *worse* than allowing to configure them
properly. So if someone voices "but we want only PMD-sized" ones, the
next one will say "but we only want cont-pte sized-ones" and then we
should provide an option to control the actual sizes to use differently,
in some way. But let's see if that is even required.
--
Cheers,
David / dhildenb
