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

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

[-- Attachment #1: Type: text/plain, Size: 3395 bytes --]

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



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

[-- Attachment #2: Type: text/html, Size: 4587 bytes --]