From: Yu Xu <xuyu@linux.alibaba.com>
To: Hugh Dickins <hughd@google.com>, Matthew Wilcox <willy@infradead.org>
Cc: 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: Wed, 2 Jun 2021 11:27:47 +0800 [thread overview]
Message-ID: <71c320bf-3fcb-f8c0-65e4-ff706af05607@linux.alibaba.com> (raw)
In-Reply-To: <alpine.LSU.2.11.2106011114580.1045@eggly.anvils>
On 6/2/21 3:10 AM, Hugh Dickins wrote:
> 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
I ever considered about using compound_head, but isn't there another
race that, the following put_and_wait_on_page_locked operates on the
"tail page" which has been split and is now a single page?
Anyway, I will test and verify compound_head.
> 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.
Agreed. I will send v2, if cond_resched is still an option.
>
> Waiting on migration entries from THP splitting is an egregious
> example, but others may be suffering too.
>
> Hugh
>
--
Thanks,
Yu
next prev parent reply other threads:[~2021-06-02 3:27 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-01 16:31 [PATCH] mm, thp: relax migration wait when failed to get tail page 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
2021-06-01 20:27 ` Matthew Wilcox
2021-06-02 3:27 ` Yu Xu [this message]
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=71c320bf-3fcb-f8c0-65e4-ff706af05607@linux.alibaba.com \
--to=xuyu@linux.alibaba.com \
--cc=akpm@linux-foundation.org \
--cc=gavin.dg@linux.alibaba.com \
--cc=gthelen@google.com \
--cc=hughd@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 \
/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;
as well as URLs for NNTP newsgroup(s).