Re: [PATCH v4 00/16] Overhaul multi-page lookups for THP

From: Hugh Dickins <hughd@google.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Hugh Dickins <hughd@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jan Kara <jack@suse.cz>,
	William Kucharski <william.kucharski@oracle.com>,
	Linux-FSDevel <linux-fsdevel@vger.kernel.org>,
	linux-mm <linux-mm@kvack.org>, Christoph Hellwig <hch@lst.de>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Yang Shi <yang.shi@linux.alibaba.com>,
	dchinner@redhat.com, linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 00/16] Overhaul multi-page lookups for THP
Date: Mon, 30 Nov 2020 11:45:46 -0800 (PST)	[thread overview]
Message-ID: <alpine.LSU.2.11.2011301109230.17996@eggly.anvils> (raw)
In-Reply-To: <20201126200703.GW4327@casper.infradead.org>

On Thu, 26 Nov 2020, Matthew Wilcox wrote:
> On Thu, Nov 26, 2020 at 11:24:59AM -0800, Hugh Dickins wrote:
> 
> > But right now it's the right fix that's important: ack to yours below.
> > 
> > I've not yet worked out the other issues I saw: will report when I have.
> > Rebooted this laptop, pretty sure it missed freeing a shmem swap entry,
> > not yet reproduced, will study the change there later, but the non-swap 
> > hang in generic/476 (later seen also in generic/112) more important.

It's been a struggle, but I do now have a version of shmem_undo_range()
that works reliably, no known bugs, with no changes to your last version
outside of shmem_undo_range().

But my testing so far has been with the initial optimization loop (of
trylocks in find_lock_entries()) "#if 0"ed out, to give the final loop
a harder time. Now I'll bring back that initial loop (maybe cleaning up
some start/end variables) and retest - hoping not to regress as I do so.

I'll send it late today: I expect I'll just send the body of
shmem_undo_range() itself, rather than a diff, since it's too confusing
to know what to diff against.  Or, maybe you now have your own improved
version, and will want me to look at yours rather than sending mine.

Andrew, if you're planning another mmotm soon, please remove/comment
mm-truncateshmem-handle-truncates-that-split-thps.patch
and any of its "fixes" as to-be-updated: all versions to date
have been too buggy to keep, and a new version will require its own
review, as you noted. I think that means you also have to remove
mm-filemap-return-only-head-pages-from-find_get_entries.patch
which I think is blameless, but may depend on it logically.

> 
> The good news is that I've sorted out the SCRATCH_DEV issue with
> running xfstests.  The bad news is that (even on an unmodified kernel),
> generic/027 takes 19 hours to run.  On xfs, it's 4 minutes.  Any idea
> why it's so slow on tmpfs?

I sent a tarball of four xfstests patches on Thursday, they're valid:
but generic/075 and generic/112, very useful for this testing, suffer
from an fsx build bug which might or might not affect you: so I'll now
reply to that mail with latest tarball.

Hugh