From: Hugh Dickins <hughd@google.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Hugh Dickins <hughd@google.com>, Xu Yu <xuyu@linux.alibaba.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
akpm@linux-foundation.org, gavin.dg@linux.alibaba.com,
Greg Thelen <gthelen@google.com>, Wei Xu <weixugc@google.com>,
Nicholas Piggin <npiggin@gmail.com>,
Vlastimil Babka <vbabka@suse.cz>
Subject: Re: [PATCH] mm, thp: relax migration wait when failed to get tail page
Date: Tue, 1 Jun 2021 12:10:48 -0700 (PDT) [thread overview]
Message-ID: <alpine.LSU.2.11.2106011114580.1045@eggly.anvils> (raw)
In-Reply-To: <YLZqKJ4anEGpAZfp@casper.infradead.org>
On Tue, 1 Jun 2021, Matthew Wilcox wrote:
> On Tue, Jun 01, 2021 at 09:55:56AM -0700, Hugh Dickins wrote:
> >
> > Well caught: you're absolutely right that there's a bug there.
> > But isn't cond_resched() just papering over the real bug, and
> > what it should do is a "page = compound_head(page);" before the
> > get_page_unless_zero()? How does that work out in your testing?
>
> You do realise you're strengthening my case for folios by suggesting
> that, don't you? ;-)
Hah! Well, I do realize that I'm offering you a marketing opportunity.
And you won't believe how many patches I dread to post for fear of that ;-)
But I'm not so sure that it strengthens your case: apparently folios
had not detected this? Or do you have a hoard of folio-detected fixes
waiting for the day, and a folio-kit for each of the stable releases?
>
> I was going to suggest that it won't make any difference because the
> page reference count is frozen, but the freezing happens after the call
> to unmap_page(), so it may make a difference.
I think that's a good point: I may have just jumped on the missing
compound_head(), without thinking it through as far as you have.
I'm having trouble remembering the dynamics now; but I think there
are cond_resched()s in the unmap_page() part, so the splitter may
get preempted even on a non-preempt kernel; whereas the frozen
part is all done expeditiously, with interrupts disabled.
Greg discovered the same issue recently, but we all got sidetracked,
and I don't know where his investigation ended up. He was in favour
of cond_resched(), I was in favour of compound_head(); and I think I
was coming to the conclusion that if cond_resched() is needed, it
should not be there in __migration_entry_wait(), but somewhere up
in mm/gup.c, so that other faults that retry, expecting to reschedule
on return to userspace, do not get trapped in kernelspace this way.
Waiting on migration entries from THP splitting is an egregious
example, but others may be suffering too.
Hugh
next prev parent reply other threads:[~2021-06-01 19:10 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-01 16:31 Xu Yu
2021-06-01 16:49 ` Matthew Wilcox
2021-06-01 16:55 ` Hugh Dickins
2021-06-01 17:11 ` Matthew Wilcox
2021-06-01 19:10 ` Hugh Dickins [this message]
2021-06-01 20:27 ` Matthew Wilcox
2021-06-02 3:27 ` Yu Xu
2021-06-02 11:58 ` Matthew Wilcox
2021-06-02 12:59 ` Yu Xu
2021-06-02 13:20 ` Yu Xu
2021-06-02 15:57 ` Hugh Dickins
2021-06-07 7:24 ` Yu Xu
2021-06-08 4:44 ` Hugh Dickins
2021-06-08 5:43 ` Yu Xu
2021-06-08 6:53 ` Hugh Dickins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LSU.2.11.2106011114580.1045@eggly.anvils \
--to=hughd@google.com \
--cc=akpm@linux-foundation.org \
--cc=gavin.dg@linux.alibaba.com \
--cc=gthelen@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=npiggin@gmail.com \
--cc=vbabka@suse.cz \
--cc=weixugc@google.com \
--cc=willy@infradead.org \
--cc=xuyu@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox