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: <CACePvbVufm1=hwZx=is7XxrpVvJnYES4QPWvrsRZM-Ci7kDPNQ@mail.gmail.com>
Date: Mon, 15 Jul 2024 11:14:45 -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 Mon, Jul 15, 2024 at 7:10 AM Ryan Roberts <ryan.roberts@....com> wrote:
>
> On 11/07/2024 15:08, Chris Li wrote:
> > 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.
>
> OK, that certainly makes sense, as long as you're sure its noise. The other
> (unlikely) possibility is that somehow the HDD placement descisions are
> changing, which increases waiting due to increased seek times.

I sure did not change the HDD placement, if the HDD allocation is
different from the previous code, that should be a bug.
I mostly remove the cluster code path in HDD swap entry allocation.

I did the HDD run mostly to make sure the HDD can still take some
stress test on the swapping without crashing.

Chris