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 3B5E8C433F5 for ; Sat, 28 May 2022 03:13:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 82FC48D0003; Fri, 27 May 2022 23:13:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7B7978D0002; Fri, 27 May 2022 23:13:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 679888D0003; Fri, 27 May 2022 23:13:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 554C88D0002 for ; Fri, 27 May 2022 23:13:56 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 28899606AB for ; Sat, 28 May 2022 03:13:56 +0000 (UTC) X-FDA: 79513682472.09.5FE6578 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf08.hostedemail.com (Postfix) with ESMTP id 31FB516003C for ; Sat, 28 May 2022 03:13:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=QAV4mbxWazsO8YI+Vd3NhlfoJMrxEgaww3Nl7Ft7sy4=; b=ZpwWawJzT58qGKFSMIk13M/5FC 9p4UrV/OxAVmLzgYIuRYwdT1bWDnNot5OeYhdm+Bidr0fiKQ4CWpAUqywxsPJL4hpnKnEq4XSl4Rp A1qPMJzt5ONRDli75IUUaJ5+UD/EmHRx+l10pLYlD3C5LjTEvAyXZypMh+mEASRLXAO6bNg7y84C1 g1YCoV+Tgqsfglro7Ukg9ZATC4hWSk3gz9AaDNsxpj4H8NptO6gq264WTDZeC/gOWudy2FIC5LQDy BSrL19E88Vvriw39YyroU4Lsta6eqdaSSwC8q6l/O4bUooCm5Kc/Q7aRrdYP6dRI5zdEnYgyVQxeX +m8jRzPA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1numtc-002Zpk-19; Sat, 28 May 2022 03:13:44 +0000 Date: Sat, 28 May 2022 04:13:44 +0100 From: Matthew Wilcox To: Miaohe Lin Cc: akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/vmscan: don't try to reclaim freed folios Message-ID: References: <20220527080451.48549-1-linmiaohe@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 31FB516003C X-Stat-Signature: hemn3hmuz5duw84c3tt5a6xhrrysb8sh Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=ZpwWawJz; dmarc=none; spf=none (imf08.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org X-HE-Tag: 1653707612-593087 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 Sat, May 28, 2022 at 10:52:11AM +0800, Miaohe Lin wrote: > On 2022/5/27 23:02, Matthew Wilcox wrote: > > 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? Take a look at something like GUP (fast). If this page _was_ mapped to userspace, something like this can happen: Thread A Thread B load PTE unmap page refcount goes to 1 vmscan sees the page try_get_ref refcount is now 2. WARN_ON. Thread A will see that the PTE has changed and will now drop its reference, but Thread B already spat out the WARN. A similar thing can happen with the page cache. If this is a worthwhile optimisation (does it happen often that we find a refcount == 1 page?), we could do something like ... if (folio_ref_freeze(folio, 1)) { nr_pages = folio_nr_pages(folio); goto free_it; } ... or ... if (folio_ref_count(folio) == 1 && folio_ref_freeze(folio, 1)) { ... if we want to test-and-test-and-clear But this function is far too complicated already. I really want to see numbers that proves the extra complexity is worth it.