Message ID | 20221205140327.72304-1-wangkefeng.wang@huawei.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp2264122wrr; Mon, 5 Dec 2022 05:50:21 -0800 (PST) X-Google-Smtp-Source: AA0mqf69JukodX9bxZvtRCeI81utcMyOlj5S74YKdeekNuwioVOtAjcHoc2M4aokc0o5FJUXX3e/ X-Received: by 2002:a05:6402:5305:b0:467:69e3:c25b with SMTP id eo5-20020a056402530500b0046769e3c25bmr72927195edb.3.1670248221217; Mon, 05 Dec 2022 05:50:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670248221; cv=none; d=google.com; s=arc-20160816; b=YVpQcyJZ5GUfBR2aFAGw7bUN3efqagCWbaFIZDSxyCvjde+Oj0104uOtn6VtaVRVok xFKkgC44It2gW8wOnlp0u7JrAFuWJHw0u+UNI+TzD8AJ14+IyP8glZFg5wgxJt5rws+C Sbke8Tcoz14LWwDMjclxIMITVGAldZZElYmxk9OsfwOwl1BtrUSfmz/j7dU//3s1MF+m jXFKUDdJRKUKqDlqU+JrxCH8fpNDN7bSmlSM2OD0adhwlHVsmevpdYXylIemCSG8H0tR p8LKxGzDRGCVNhBCZo1WQss3qsCCynFsujbbIVuN+162Gea3ZpJHMrYLak1LaFTJjQYT W5EA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=Zx8ryHtLNfgNEld6vz5aC14DFYoVAPc/4p+ocezuNVM=; b=QSWpLMDXuCmsqw4BvWG5qnMa04ihEt4FhsXb7O5q2PTlgKdizHbzkx4HjT/Cb2tTwN wtxbHLANzluS/OikepFcreu1n3MYhUnO8fAUa1ePH+oyapaNCQlguZlr5/HgDbUrTB3A w3vgJmVm5xYq6EQOUxep594o49hmqXwnleRhLOheZt9H1sd6N/RhxkD2cddgKRK8acTW SX52nWZcQpBFa5KfcYuJniUz6JkNqdjbWzRFzvBLp3lDgBI7rWFU2l95M+htggs/Cid/ gsTYE95eAZNjm9O2PPJI0FLCZ1r2hKi3PHhReALUIFgnOJOBNjo2qT/y8u8s4UMwpOys 9gFA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x3-20020a05640226c300b0045782fcb80asi12578346edd.225.2022.12.05.05.49.56; Mon, 05 Dec 2022 05:50:21 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230350AbiLENtZ (ORCPT <rfc822;jaysivo@gmail.com> + 99 others); Mon, 5 Dec 2022 08:49:25 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43084 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229949AbiLENtX (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 5 Dec 2022 08:49:23 -0500 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D6C9F11813 for <linux-kernel@vger.kernel.org>; Mon, 5 Dec 2022 05:49:22 -0800 (PST) Received: from dggpemm500001.china.huawei.com (unknown [172.30.72.56]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4NQlJ02rFVzRpl4; Mon, 5 Dec 2022 21:48:32 +0800 (CST) Received: from localhost.localdomain.localdomain (10.175.113.25) by dggpemm500001.china.huawei.com (7.185.36.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Mon, 5 Dec 2022 21:49:20 +0800 From: Kefeng Wang <wangkefeng.wang@huawei.com> To: Andrew Morton <akpm@linux-foundation.org>, <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org> CC: <xialonglong1@huawei.com>, Kefeng Wang <wangkefeng.wang@huawei.com> Subject: [PATCH] mm: add cond_resched() in swapin_walk_pmd_entry() Date: Mon, 5 Dec 2022 22:03:27 +0800 Message-ID: <20221205140327.72304-1-wangkefeng.wang@huawei.com> X-Mailer: git-send-email 2.35.3 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.175.113.25] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To dggpemm500001.china.huawei.com (7.185.36.107) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1751382199202641402?= X-GMAIL-MSGID: =?utf-8?q?1751382199202641402?= |
Series |
mm: add cond_resched() in swapin_walk_pmd_entry()
|
|
Commit Message
Kefeng Wang
Dec. 5, 2022, 2:03 p.m. UTC
When handle MADV_WILLNEED in madvise(), the soflockup may be occurred
in swapin_walk_pmd_entry() if swapin lots of memory on slow device,
add a cond_resched() into it to avoid the possible softlockup.
Fixes: 1998cc048901 ("mm: make madvise(MADV_WILLNEED) support swap file prefetch")
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---
mm/madvise.c | 1 +
1 file changed, 1 insertion(+)
Comments
On Mon, 5 Dec 2022 22:03:27 +0800 Kefeng Wang <wangkefeng.wang@huawei.com> wrote: > When handle MADV_WILLNEED in madvise(), the soflockup may be occurred > in swapin_walk_pmd_entry() if swapin lots of memory on slow device, > add a cond_resched() into it to avoid the possible softlockup. > > ... > > --- a/mm/madvise.c > +++ b/mm/madvise.c > @@ -226,6 +226,7 @@ static int swapin_walk_pmd_entry(pmd_t *pmd, unsigned long start, > put_page(page); > } > swap_read_unplug(splug); > + cond_resched(); > > return 0; > } I wonder if this would be better in walk_pmd_range(), to address other very large walk attempts.
On 2022/12/6 5:03, Andrew Morton wrote: > On Mon, 5 Dec 2022 22:03:27 +0800 Kefeng Wang <wangkefeng.wang@huawei.com> wrote: > >> When handle MADV_WILLNEED in madvise(), the soflockup may be occurred >> in swapin_walk_pmd_entry() if swapin lots of memory on slow device, >> add a cond_resched() into it to avoid the possible softlockup. >> >> ... >> >> --- a/mm/madvise.c >> +++ b/mm/madvise.c >> @@ -226,6 +226,7 @@ static int swapin_walk_pmd_entry(pmd_t *pmd, unsigned long start, >> put_page(page); >> } >> swap_read_unplug(splug); >> + cond_resched(); >> >> return 0; >> } > I wonder if this would be better in walk_pmd_range(), to address other > very large walk attempts. mm/madvise.c:287: walk_page_range(vma->vm_mm, start, end, &swapin_walk_ops, vma); mm/madvise.c:514: walk_page_range(vma->vm_mm, addr, end, &cold_walk_ops, &walk_private); mm/madvise.c:762: walk_page_range(vma->vm_mm, range.start, range.end, mm/madvise.c-763- &madvise_free_walk_ops, &tlb); The cold_walk_ops and madvise_free_walk_ops are already with cond_resched() in theirs pmd_entry walk, maybe there's no need for a precautionary increase a cond_resched() for now > > .
diff --git a/mm/madvise.c b/mm/madvise.c index b913ba6efc10..fea589d8a2fb 100644 --- a/mm/madvise.c +++ b/mm/madvise.c @@ -226,6 +226,7 @@ static int swapin_walk_pmd_entry(pmd_t *pmd, unsigned long start, put_page(page); } swap_read_unplug(splug); + cond_resched(); return 0; }