On 31.08.23 14:29, Matthew Wilcox wrote:
On Thu, Aug 31, 2023 at 09:57:46AM +0200, David Hildenbrand wrote:
As raised in another mail, we can then discuss
* how we want to call this feature (transparent large pages? there is
the concern that "THP" might confuse users. Maybe we can consider
"large" the more generic version and "huge" only PMD-size, TBD)
* how to expose it in stats towards the user (e.g., /proc/meminfo)
* which minimal toggles we want
I think there *really* has to be a way to disable it for a running system,
otherwise no distro will dare pulling it in, even after we figured out the
other stuff.
Note that for the pagecache, large folios can be disabled and distributions
are actively making use of that.
You can't. Well, you can for shmem/tmpfs, but you have to edit the
source code or disable CONFIG_TRANSPARENT_HUGEPAGE to disable it for XFS.
While you cannot currently control the exact allocation granularity, you
can limit the effect it has on apps that are sensitive to rss (memcg)
changes. See
See as an example:
https://www.suse.com/support/kb/doc/?id=000019017
For the pagecache you arguably don't care, because the assumption is
that you can reclaim that memory anytime. So even if you allocated 2 MiB
and only mapped 4 KiB into the process, so far you can work around that
breaking existing setups by setting fault_around_bytes.
For anon memory that's quite different (as of now and in the forseable
future). For that reason, we have all these knobs to teach THP to not
over-allocate memory (e.g., no thp on page fault, don't fill holes in
khugepaged).
I know that Dave R. can share quite some details about that.
--
Cheers,
David / dhildenb
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
