linux-kernel - Re: [PATCH v4 0/3] mm: swap: mTHP swap allocator base on swap cluster order

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACePvbX99r8BNZTkax=KGBx-XYP6WLxZKez3qsi+FfreC2TwGg@mail.gmail.com>
Date: Thu, 11 Jul 2024 07:08:07 -0700
From: Chris Li <chrisl@...nel.org>
To: Ryan Roberts <ryan.roberts@....com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, Kairui Song <kasong@...cent.com>, 
	Hugh Dickins <hughd@...gle.com>, "Huang, Ying" <ying.huang@...el.com>, 
	Kalesh Singh <kaleshsingh@...gle.com>, linux-kernel@...r.kernel.org, linux-mm@...ck.org, 
	Barry Song <baohua@...nel.org>
Subject: Re: [PATCH v4 0/3] mm: swap: mTHP swap allocator base on swap cluster order

On Thu, Jul 11, 2024 at 3:02 AM Ryan Roberts <ryan.roberts@....com> wrote:
>
> > Kernel compile under tmpfs with cgroup memory.max = 2G.
> > 12 core 24 hyperthreading, 32 jobs.
> >
> > HDD swap 3 runs average, 20G swap file:
> >
> > Without:
> > user  4186.290
> > system        421.743
> > real  597.317
> >
> > With:
> > user  4113.897
> > system        413.123
> > real  659.543
>
> If I've understood this correctly, this test is taking~10% longer in wall time?

Most likely due to the high variance in measurement and fewer
measuring samples 3 vs 10. Most of that wall time is waiting for IO.
It is likely just noise.

> But your changes shouldn't affect HDD swap path? So what's the reason for this?

The change did affect HDD swap path in the sense that it did not need
to check for si->cluster_info any more. A small gain there.

The wall clock time is more than double the SSD or zram. Which means
most of the time the system is waiting for HDD IO to complete (wait is
98%) , there will be much higher variance for sure. At this point the
wall clock we are measuring the wait mostly,  not the actual work. The
system time is quicker, that is good.

I now have a dedicated machine to run the HDD swap now. The HDD is
very very slow to swap. The point of the HDD test is being able to
complete the run without OOM. Because of the high latency in HDD,
there will be more memory pressure. It did catch some other bugs in my
internal version of the patch.

> I'm hoping to review this properly next week. It would be great to get this in
> sooner rather than later IMHO.

Thank you. This new code path is much easier to work with than the
previous SSD and HDD mixed allocation path. I am able to implement the
cluster reservation experiment in the new allocator much quicker.

Chris