From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.9 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY, USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 12327C4708F for ; Wed, 2 Jun 2021 13:20:40 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8AD2F6024A for ; Wed, 2 Jun 2021 13:20:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8AD2F6024A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id BF07E6B006C; Wed, 2 Jun 2021 09:20:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BA0D16B006E; Wed, 2 Jun 2021 09:20:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A1A146B0070; Wed, 2 Jun 2021 09:20:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0253.hostedemail.com [216.40.44.253]) by kanga.kvack.org (Postfix) with ESMTP id 6DC186B006C for ; Wed, 2 Jun 2021 09:20:38 -0400 (EDT) Received: from smtpin40.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 091C4A2BE for ; Wed, 2 Jun 2021 13:20:38 +0000 (UTC) X-FDA: 78208843356.40.B9D2607 Received: from out30-131.freemail.mail.aliyun.com (out30-131.freemail.mail.aliyun.com [115.124.30.131]) by imf21.hostedemail.com (Postfix) with ESMTP id 6A324E000240 for ; Wed, 2 Jun 2021 13:20:19 +0000 (UTC) X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R181e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e01424;MF=xuyu@linux.alibaba.com;NM=1;PH=DS;RN=11;SR=0;TI=SMTPD_---0Ub3L4fy_1622640032; Received: from xuyu-mbp15.local(mailfrom:xuyu@linux.alibaba.com fp:SMTPD_---0Ub3L4fy_1622640032) by smtp.aliyun-inc.com(127.0.0.1); Wed, 02 Jun 2021 21:20:33 +0800 Subject: Re: [PATCH] mm, thp: relax migration wait when failed to get tail page To: Hugh Dickins Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, gavin.dg@linux.alibaba.com, Greg Thelen , Wei Xu , Matthew Wilcox , Nicholas Piggin , Vlastimil Babka References: From: Yu Xu Message-ID: Date: Wed, 2 Jun 2021 21:20:32 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Authentication-Results: imf21.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=alibaba.com; spf=pass (imf21.hostedemail.com: domain of xuyu@linux.alibaba.com designates 115.124.30.131 as permitted sender) smtp.mailfrom=xuyu@linux.alibaba.com X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 6A324E000240 X-Stat-Signature: s3b7pou9iewa8564eom6645mwp7sg976 X-HE-Tag: 1622640019-748107 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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 >> Signed-off-by: Xu Yu > > 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