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

[Ryan Roberts <ryan.roberts@arm.com>]

On 11/07/2024 15:08, Chris Li wrote:
> On Thu, Jul 11, 2024 at 3:02 AM Ryan Roberts <ryan.roberts@arm.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.

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