From: Yu Xu <xuyu@linux.alibaba.com>
To: Hugh Dickins <hughd@google.com>
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>,
Matthew Wilcox <willy@infradead.org>,
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 21:20:32 +0800 [thread overview]
Message-ID: <b05ab98d-3a0d-ec23-96dd-5c970aa61580@linux.alibaba.com> (raw)
In-Reply-To: <alpine.LSU.2.11.2106010947370.1090@eggly.anvils>
On 6/2/21 12:55 AM, Hugh Dickins wrote:
> On Wed, 2 Jun 2021, Xu Yu wrote:
>
>> We notice that hung task happens in a conner but practical scenario when
>> CONFIG_PREEMPT_NONE is enabled, as follows.
>>
>> Process 0 Process 1 Process 2..Inf
>> split_huge_page_to_list
>> unmap_page
>> split_huge_pmd_address
>> __migration_entry_wait(head)
>> __migration_entry_wait(tail)
>> remap_page (roll back)
>> remove_migration_ptes
>> rmap_walk_anon
>> cond_resched
>>
>> Where __migration_entry_wait(tail) is occurred in kernel space, e.g.,
>> copy_to_user, which will immediately fault again without rescheduling,
>> and thus occupy the cpu fully.
>>
>> When there are too many processes performing __migration_entry_wait on
>> tail page, remap_page will never be done after cond_resched.
>>
>> This relaxes __migration_entry_wait on tail page, thus gives remap_page
>> a chance to complete.
>>
>> Signed-off-by: Gang Deng <gavin.dg@linux.alibaba.com>
>> Signed-off-by: Xu Yu <xuyu@linux.alibaba.com>
>
> 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?
compound_head works. The patched kernel is alive for hours under
our reproducer, which usually makes the vanilla kernel hung after
tens of minutes at most.
If we use compound_head, the behavior of __migration_entry_wait(tail)
changes from "retry fault" to "prevent THP from being split". Is that
right? Then which is preferred? If it were me, I would prefer "retry
fault".
>
> Hugh
>
>> ---
>> mm/migrate.c | 7 +++++--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/mm/migrate.c b/mm/migrate.c
>> index b234c3f3acb7..df2dc39fe566 100644
>> --- a/mm/migrate.c
>> +++ b/mm/migrate.c
>> @@ -301,8 +301,11 @@ void __migration_entry_wait(struct mm_struct *mm, pte_t *ptep,
>> * is zero; but we must not call put_and_wait_on_page_locked() without
>> * a ref. Use get_page_unless_zero(), and just fault again if it fails.
>> */
>> - if (!get_page_unless_zero(page))
>> - goto out;
>> + if (!get_page_unless_zero(page)) {
>> + pte_unmap_unlock(ptep, ptl);
>> + cond_resched();
>> + return;
>> + }
>> pte_unmap_unlock(ptep, ptl);
>> put_and_wait_on_page_locked(page, TASK_UNINTERRUPTIBLE);
>> return;
>> --
>> 2.20.1.2432.ga663e714
>>
>>
>>
--
Thanks,
Yu
next prev parent reply other threads:[~2021-06-02 13:20 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
2021-06-02 11:58 ` Matthew Wilcox
2021-06-02 12:59 ` Yu Xu
2021-06-02 13:20 ` Yu Xu [this message]
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=b05ab98d-3a0d-ec23-96dd-5c970aa61580@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.