Re: [PATCH v4 2/5] mm: LARGE_ANON_FOLIO for improved performance

From: Ryan Roberts
Date: Thu Aug 03 2023 - 05:32:27 EST


On 03/08/2023 09:37, Yin Fengwei wrote:
>
>
> On 8/3/23 16:21, Ryan Roberts wrote:
>> On 03/08/2023 09:05, Yin Fengwei wrote:
>>
>> ...
>>
>>>> I've captured run time and peak memory usage, and taken the mean. The stdev for
>>>> the peak memory usage is big-ish, but I'm confident this still captures the
>>>> central tendancy well:
>>>>
>>>> | MAX_ORDER_UNHINTED | real-time | kern-time | user-time | peak memory |
>>>> |:-------------------|------------:|------------:|------------:|:------------|
>>>> | 4k | 0.0% | 0.0% | 0.0% | 0.0% |
>>>> | 16k | -3.6% | -26.5% | -0.5% | -0.1% |
>>>> | 32k | -4.8% | -37.4% | -0.6% | -0.1% |
>>>> | 64k | -5.7% | -42.0% | -0.6% | -1.1% |
>>>> | 128k | -5.6% | -42.1% | -0.7% | 1.4% |
>>>> | 256k | -4.9% | -41.9% | -0.4% | 1.9% |
>>>
>>> Here is my test result:
>>>
>>> real user sys
>>> hink-4k: 0% 0% 0%
>>> hink-16K: -3% 0.1% -18.3%
>>> hink-32K: -4% 0.2% -27.2%
>>> hink-64K: -4% 0.5% -31.0%
>>> hink-128K: -4% 0.9% -33.7%
>>> hink-256K: -5% 1% -34.6%
>>>
>>>
>>> I used command:
>>> /usr/bin/time -f "\t%E real,\t%U user,\t%S sys" make -skj96 allmodconfig all
>>> to build kernel and collect the real time/user time/kernel time.
>>> /sys/kernel/mm/transparent_hugepage/enabled is "madvise".
>>> Let me know if you have any question about the test.
>>
>> Thanks for doing this! I have a couple of questions:
>>
>> - how many times did you run each test?
> Three times for each ANON_FOLIO_MAX_ORDER_UNHINTED. The stddev is quite
> small like less than %1.

And out of interest, were you running on bare metal or in VM? And did you reboot
between each run?

>>
>> - how did you configure the large page size? (I sent an email out yesterday
>> saying that I was doing it wrong from my tests, so the 128k and 256k results
>> for my test set are not valid.
> I changed the ANON_FOLIO_MAX_ORDER_UNHINTED definition manually every time.

In that case, I think your results are broken in a similar way to mine. This
code means that order will never be higher than 3 (32K) on x86:

+ order = max(arch_wants_pte_order(), PAGE_ALLOC_COSTLY_ORDER);
+
+ if (!hugepage_vma_check(vma, vma->vm_flags, false, true, true))
+ order = min(order, ANON_FOLIO_MAX_ORDER_UNHINTED);

On x86, arch_wants_pte_order() is not implemented and the default returns -1, so
you end up with:

order = min(PAGE_ALLOC_COSTLY_ORDER, ANON_FOLIO_MAX_ORDER_UNHINTED)

So your 4k, 16k and 32k results should be valid, but 64k, 128k and 256k results
are actually using 32k, I think? Which is odd because you are getting more
stddev than the < 1% you quoted above? So perhaps this is down to rebooting
(kaslr, or something...?)

(on arm64, arch_wants_pte_order() returns 4, so my 64k result is also valid).

As a quick hack to work around this, would you be able to change the code to this:

+ if (!hugepage_vma_check(vma, vma->vm_flags, false, true, true))
+ order = ANON_FOLIO_MAX_ORDER_UNHINTED;

>
>>
>> - what does "hink" mean??
> Sorry for the typo. It should be ANON_FOLIO_MAX_ORDER_UNHINTED.
>
>>
>>>
>>> I also find one strange behavior with this version. It's related with why
>>> I need to set the /sys/kernel/mm/transparent_hugepage/enabled to "madvise".
>>> If it's "never", the large folio is disabled either.
>>> If it's "always", the THP will be active before large folio. So the system is
>>> in the mixed mode. it's not suitable for this test.
>>
>> We had a discussion around this in the THP meeting yesterday. I'm going to write
>> this up propoerly so we can have proper systematic discussion. The tentative
>> conclusion is that MADV_NOHUGEPAGE must continue to mean "do not fault in more
>> than is absolutely necessary". I would assume we need to extend that thinking to
>> the process-wide and system-wide knobs (as is done in the patch), but we didn't
>> explicitly say so in the meeting.
> There are cases that THP is not appreciated because of the latency or memory
> consumption. For these cases, large folio may fill the gap as less latency and
> memory consumption.
>
>
> So if disabling THP means large folio can't be used, we loose the chance to
> benefit those cases with large folio.

Yes, I appreciate that. But there are also real use cases that expect
MADV_NOHUGEPAGE means "do not fault more than is absolutely necessary" and the
use cases break if that's not obeyed (e.g. live migration w/ qemu). So I think
we need to be conservitive to start. These apps that are explicitly forbidding
THP today, should be updated in the long run to opt-in to large anon folios
using some as-yet undefined control.

>
>
> Regards
> Yin, Fengwei
>
>>
>> My intention is that if you have requested THP and your vma is big enough for
>> PMD-size then you get that, else you fallback to large anon folios. And if you
>> have neither opted in nor out, then you get large anon folios.
>>
>> We talked about the idea of adding a new knob that let's you set the max order,
>> but that needs a lot more thought.
>>
>> Anyway, as I said, I'll write it up so we can all systematically discuss.
>>
>>>
>>> So if it's "never", large folio is disabled. But why "madvise" enables large
>>> folio unconditionly? Suppose it's only enabled for the VMA range which user
>>> madvise large folio (or THP)?
>>>
>>> Specific for the hink setting, my understand is that we can't choose it only
>>> by this testing. Other workloads may have different behavior with differnt
>>> hink setting.
>>>
>>>
>>> Regards
>>> Yin, Fengwei
>>>
>>