Re: [PATCH v2 0/2] mm: swap: mTHP swap allocator base on swap cluster order

[Barry Song <21cnbao@gmail.com>]

On Mon, Jun 17, 2024 at 3:12 PM Barry Song <21cnbao@gmail.com> wrote:
>
>
>
> 在 2024年6月17日星期一，Huang, Ying <ying.huang@intel.com> 写道：
>>
>>
>> Barry Song <21cnbao@gmail.com> writes:
>>
>> > On Sat, Jun 15, 2024 at 2:59 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>> >>
>> >> On Fri, 14 Jun 2024 19:51:11 -0700 Chris Li <chrisl@kernel.org> wrote:
>> >>
>> >> > > I'm having trouble understanding the overall impact of this on users.
>> >> > > We fail the mTHP swap allocation and fall back, but things continue to
>> >> > > operate OK?
>> >> >
>> >> > Continue to operate OK in the sense that the mTHP will have to split
>> >> > into 4K pages before the swap out, aka the fall back. The swap out and
>> >> > swap in can continue to work as 4K pages, not as the mTHP. Due to the
>> >> > fallback, the mTHP based zsmalloc compression with 64K buffer will not
>> >> > happen. That is the effect of the fallback. But mTHP swap out and swap
>> >> > in is relatively new, it is not really a regression.
>> >>
>> >> Sure, but it's pretty bad to merge a new feature only to have it
>> >> ineffective after a few hours use.
>> >>
>> >> > >
>> >> > > > There is some test number in the V1 thread of this series:
>> >> > > > https://lore.kernel.org/r/20240524-swap-allocator-v1-0-47861b423b26@kernel.org
>> >> > >
>> >> > > Well, please let's get the latest numbers into the latest patchset.
>> >> > > Along with a higher-level (and quantitative) description of the user impact.
>> >> >
>> >> > I will need Barray's help to collect the number. I don't have the
>> >> > setup to reproduce his test result.
>> >> > Maybe a follow up commit message amendment for the test number when I get it?
>> >
>> > Although the issue may seem complex at a systemic level, even a small program can
>> > demonstrate the problem and highlight how Chris's patch has improved the
>> > situation.
>> >
>> > To demonstrate this, I designed a basic test program that maximally allocates
>> > two memory blocks:
>> >
>> >  *   A memory block of up to 60MB, recommended for HUGEPAGE usage
>> >  *   A memory block of up to 1MB, recommended for NOHUGEPAGE usage
>> >
>> > In the system configuration, I enabled 64KB mTHP and 64MB zRAM, providing more than
>> > enough space for both the 60MB and 1MB allocations in the worst case. This setup
>> > allows us to assess two effects:
>> >
>> > 1.  When we don't enable mem2 (small folios), we consistently allocate and free
>> >     swap slots aligned with 64KB.  whether there is a risk of failure to obtain
>> >     swap slots even though the zRAM has sufficient free space?
>> > 2.  When we enable mem2 (small folios), the presence of small folios may lead
>> >     to fragmentation of clusters, potentially impacting the swapout process for
>> >     large folios negatively.
>> >
>>
>> IIUC, the test results are based on not-yet-merged patchset [1] (mm:
>> support large folios swap-in)?
>
>
> no. this data is based on mm-unstable.
>
> the visible impact is that swapping out mthp will have 14% regression if
> fallback againest swapping out nr_pages small folios regardless if mthp swapin is there.

Ryan initially reported 14% swapout regression without mTHP swapout.
then he reported 46.3% improvement if mTHP can be swapped out as
a whole[1].

so we will drop 60%+ performance if fallback. but the 14% regression against
pure small folios are unacceptable considering more than 2/3 memory can
be swapped out on mobile devices.

So I am hoping we can find some way to merge Chris' patchset soon. though
the WARN_ONCE still indicates some BUG in v2. Hopefully, Chris can fix it
in v3.

[1] https://lore.kernel.org/all/20240408183946.2991168-1-ryan.roberts@arm.com/

>
>
>>
>> [1] https://lore.kernel.org/linux-mm/20240304081348.197341-1-21cnbao@gmail.com/
>>
>> If so, do we have any visible effect without that?  If not, should we
>> wait for patchset [1] (or something similar) to be merged firstly?
>>
>> --
>> Best Regards,
>> Huang, Ying
>>

Thanks
Barry