On 2024/5/31 19:13, David Hildenbrand wrote:
As a default, we should not be using large folios / mTHP for any shmem,
just like we did with THP via shmem_enabled. This is what this series
currently does, and is aprt of the whole mTHP user-space interface
design.
Further, the mTHP controls should control all of shmem, not only
"anonymous shmem".
Yes, that's what I thought and in my TODO list.
Good, it would be helpful to coordinate with Daniel and Pankaj.
Also, we should properly fallback within the configured sizes, and not
jump "over" configured sizes. Unless there is a good reason.
(3) khugepaged
khugepaged needs to handle larger folios properly as well. Until fixed,
using smaller THP sizes as fallback might prohibit collapsing a
PMD-sized THP later. But really, khugepaged needs to be fixed to handle
that. >
(4) force/disable
These settings are rather testing artifacts from the old ages. We should
not add them to the per-size toggles. We might "inherit" it from the
global one, though.
Sorry, I missed this. So I thould remove the 'force' and 'deny' option
for each mTHP, right?
Yes, that's my understanding. But we have to keep them on the top level
for any possible user out there.
OK.
"within_size" might have value, and especially for consistency, we
should have them per size.
So, this series only tackles anonymous shmem, which is a good starting
point. Ideally, we'd get support for other shmem (especially during
fault time) soon afterwards, because we won't be adding separate toggles
for that from the interface POV, and having inconsistent behavior
between kernel versions would be a bit unfortunate.
@Baolin, this series likely does not consider (4) yet. And I suggest we
have to take a lot of the "anonymous thp" terminology out of this
series, especially when it comes to documentation.
Sure. I will remove the "anonymous thp" terminology from the
documentation, but want to still keep it in the commit message, cause I
want to start from the anonymous shmem.
For commit message and friends makes sense. The story should be
"controls all of shmem/tmpfs, but support will be added iteratively. The
first step is anonymous shmem."
Sure. Thanks.
