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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 035B5C433EF for ; Sat, 28 May 2022 02:52:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2B5438D0003; Fri, 27 May 2022 22:52:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 263758D0002; Fri, 27 May 2022 22:52:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 14E5C8D0003; Fri, 27 May 2022 22:52:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 00F5E8D0002 for ; Fri, 27 May 2022 22:52:16 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id BA3C1204DD for ; Sat, 28 May 2022 02:52:16 +0000 (UTC) X-FDA: 79513627872.18.D23A06C Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by imf26.hostedemail.com (Postfix) with ESMTP id A774E140036 for ; Sat, 28 May 2022 02:52:11 +0000 (UTC) Received: from canpemm500002.china.huawei.com (unknown [172.30.72.54]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4L95l155Gvz1JCTL; Sat, 28 May 2022 10:50:37 +0800 (CST) Received: from [10.174.177.76] (10.174.177.76) by canpemm500002.china.huawei.com (7.192.104.244) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Sat, 28 May 2022 10:52:11 +0800 Subject: Re: [PATCH] mm/vmscan: don't try to reclaim freed folios To: Matthew Wilcox CC: , , References: <20220527080451.48549-1-linmiaohe@huawei.com> From: Miaohe Lin Message-ID: Date: Sat, 28 May 2022 10:52:11 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.177.76] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To canpemm500002.china.huawei.com (7.192.104.244) X-CFilter-Loop: Reflected X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: A774E140036 X-Rspam-User: X-Stat-Signature: gec57ofqgxdg8n9cij7i3teiksd7xpix Authentication-Results: imf26.hostedemail.com; dkim=none; spf=pass (imf26.hostedemail.com: domain of linmiaohe@huawei.com designates 45.249.212.255 as permitted sender) smtp.mailfrom=linmiaohe@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com X-HE-Tag: 1653706331-352650 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 2022/5/27 23:02, Matthew Wilcox wrote: > On Fri, May 27, 2022 at 04:04:51PM +0800, Miaohe Lin wrote: >> If folios were freed from under us, there's no need to reclaim them. Skip >> these folios to save lots of cpu cycles and avoid possible unnecessary >> disk IO. >> >> Signed-off-by: Miaohe Lin >> --- >> mm/vmscan.c | 8 +++++++- >> 1 file changed, 7 insertions(+), 1 deletion(-) >> >> diff --git a/mm/vmscan.c b/mm/vmscan.c >> index f7d9a683e3a7..646dd1efad32 100644 >> --- a/mm/vmscan.c >> +++ b/mm/vmscan.c >> @@ -1556,12 +1556,18 @@ static unsigned int shrink_page_list(struct list_head *page_list, >> folio = lru_to_folio(page_list); >> list_del(&folio->lru); >> >> + nr_pages = folio_nr_pages(folio); >> + if (folio_ref_count(folio) == 1) { >> + /* folio was freed from under us. So we are done. */ >> + WARN_ON(!folio_put_testzero(folio)); > > What? No. This can absolutely happen. We have a refcount on the folio, > which means that any other thread can temporarily raise the refcount, IIUC, the folio is only in the isolated page_list now and it's not in the page cache, swap cache, pagetable or under any use. So there should be no way that any other thread can temporarily raise the refcount when folio_ref_count == 1. Or am I miss something? > so this WARN_ON can trigger. Also, we don't hold the folio locked, > or an extra reference, so nr_pages is unstable because it can be split. Yes, you're right. When folio_ref_count != 1, nr_pages is unstable. Will fix it if v2 is possible. :) Thanks a lot for review and comment! > >> + goto free_it; >> + } >> + >> if (!folio_trylock(folio)) >> goto keep; >> >> VM_BUG_ON_FOLIO(folio_test_active(folio), folio); >> >> - nr_pages = folio_nr_pages(folio); >> >> /* Account the number of base pages */ >> sc->nr_scanned += nr_pages; >> -- >> 2.23.0 >> >> > > . >