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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 70BFFC433EF for ; Sat, 28 May 2022 02:52:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352927AbiE1CwR (ORCPT ); Fri, 27 May 2022 22:52:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35300 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231347AbiE1CwP (ORCPT ); Fri, 27 May 2022 22:52:15 -0400 Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D2A19880C6 for ; Fri, 27 May 2022 19:52:13 -0700 (PDT) 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 >> >> > > . >