Re: [PATCH v9 2/8] mm/huge_memory: add two new (not yet used) functions for folio_split()

[Hugh Dickins <hughd@google.com>]

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

On Wed, 5 Mar 2025, Zi Yan wrote:
> On 5 Mar 2025, at 16:03, Hugh Dickins wrote:
> >
> > Beyond checking that, I didn't have time yesterday to investigate
> > further, but I'll try again today (still using last weekend's mm.git).
> 
> I am trying to replicate your runs locally. Can you clarify your steps
> of “kernel builds on huge tmpfs while swapping to SSD”? Do you impose
> a memory limit so that anonymous memory is swapped to SSD or make tmpfs
> swap to SSD?

Yeah, my heart sank a bit when I saw Andrew (with good intention) asking
you to repeat my testing.

We could spend weeks going back and forth on that, and neither of us has
weeks to spare.

"To fulfil contractual obligations" I'll mail you the tarfile I send
out each time I'm asked for this; but I haven't updated that tarfile
in four years, whereas I'm frequently tweaking things to match what's
needed (most recently and relevantly, I guess enabling 64kB hugepages
for anon and shmem in addition to the PMD-sized).

Please don't waste much of your time over trying to replicate what
I'm doing: just give the scripts a glance, as a source for "oh,
I could exercise something like that in my testing too" ideas.

Yes, I limit physical memory by booting with mem=1G, and also apply
lower memcg v1 limits.

I made a point of saying "SSD" there because I'm not testing zram or
zswap at all, whereas many others are testing those rather than disk.

swapoff, and ext4 on loop0 on tmpfs, feature in what I exercise, but are
NOT relevant to the corruption I'm seeing here - that can occur before
any swapoff, and it's always on the kernel build in tmpfs: the parallel
build in ext4 on loop0 on tmpfs completes successfully.

Hugh