Re: [PATCH v3 0/6] add mTHP support for anonymous shmem

Baolin Wang
2024-05-31T10:13:07Z

On 2024/5/31 17:35, David Hildenbrand wrote:
> On 30.05.24 04:04, Baolin Wang wrote:
>> Anonymous pages have already been supported for multi-size (mTHP)
>> allocation
>> through commit 19eaf44954df, that can allow THP to be configured
>> through the
>> sysfs interface located at
>> '/sys/kernel/mm/transparent_hugepage/hugepage-XXkb/enabled'.
>>
>> However, the anonymous shmem will ignore the anonymous mTHP rule
>> configured
>> through the sysfs interface, and can only use the PMD-mapped THP, that
>> is not
>> reasonable. Many implement anonymous page sharing through
>> mmap(MAP_SHARED |
>> MAP_ANONYMOUS), especially in database usage scenarios, therefore,
>> users expect
>> to apply an unified mTHP strategy for anonymous pages, also including the
>> anonymous shared pages, in order to enjoy the benefits of mTHP. For
>> example,
>> lower latency than PMD-mapped THP, smaller memory bloat than
>> PMD-mapped THP,
>> contiguous PTEs on ARM architecture to reduce TLB miss etc.
>>
>> The primary strategy is similar to supporting anonymous mTHP. Introduce
>> a new interface '/mm/transparent_hugepage/hugepage-XXkb/shmem_enabled',
>> which can have all the same values as the top-level
>> '/sys/kernel/mm/transparent_hugepage/shmem_enabled', with adding a new
>> additional "inherit" option. By default all sizes will be set to "never"
>> except PMD size, which is set to "inherit". This ensures backward
>> compatibility
>> with the anonymous shmem enabled of the top level, meanwhile also allows
>> independent control of anonymous shmem enabled for each mTHP.
>>
>> Use the page fault latency tool to measure the performance of 1G
>> anonymous shmem
>> with 32 threads on my machine environment with: ARM64 Architecture, 32
>> cores,
>> 125G memory:
>> base: mm-unstable
>> user-time    sys_time    faults_per_sec_per_cpu     faults_per_sec
>> 0.04s        3.10s         83516.416                  2669684.890
>>
>> mm-unstable + patchset, anon shmem mTHP disabled
>> user-time    sys_time    faults_per_sec_per_cpu     faults_per_sec
>> 0.02s        3.14s         82936.359                  2630746.027
>>
>> mm-unstable + patchset, anon shmem 64K mTHP enabled
>> user-time    sys_time    faults_per_sec_per_cpu     faults_per_sec
>> 0.08s        0.31s         678630.231                 17082522.495
>>
>>  From the data above, it is observed that the patchset has a minimal
>> impact when
>> mTHP is not enabled (some fluctuations observed during testing). When
>> enabling 64K
>> mTHP, there is a significant improvement of the page fault latency.
>
> Let me summarize the takeaway from the bi-weekly MM meeting as I
> understood it, that includes Hugh's feedback on per-block tracking vs.

Thanks David for the summarization.

> mTHP:
>
> (1) Per-block tracking
>
> Per-block tracking is currently considered unwarranted complexity in
> shmem.c. We should try to get it done without that. For any test cases
> that fail, we should consider if they are actually valid for shmem.
>
> To optimize FALLOC_FL_PUNCH_HOLE for the cases where splitting+freeing
> is not possible at fallcoate() time, detecting zeropages later and
> retrying to split+free might be an option, without per-block tracking.
>
> (2) mTHP controls
>
> 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.

>
> 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?

>
> "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.

>
> @Daniel, Pankaj, what are your plans regarding that? It would be great
> if we could get an understanding on the next steps on !anon shmem.
>