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 B8834C433F5 for ; Thu, 3 Mar 2022 22:29:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1A6238D0002; Thu, 3 Mar 2022 17:29:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 156BC8D0001; Thu, 3 Mar 2022 17:29:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 01CFA8D0002; Thu, 3 Mar 2022 17:29:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0044.hostedemail.com [216.40.44.44]) by kanga.kvack.org (Postfix) with ESMTP id E820D8D0001 for ; Thu, 3 Mar 2022 17:29:00 -0500 (EST) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 86FFCA30B1 for ; Thu, 3 Mar 2022 22:29:00 +0000 (UTC) X-FDA: 79204516440.19.D0AABFE Received: from mail-oi1-f182.google.com (mail-oi1-f182.google.com [209.85.167.182]) by imf04.hostedemail.com (Postfix) with ESMTP id EE68740009 for ; Thu, 3 Mar 2022 22:28:59 +0000 (UTC) Received: by mail-oi1-f182.google.com with SMTP id q5so6181682oij.6 for ; Thu, 03 Mar 2022 14:28:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version; bh=ZitNuTrI/UQapwn2GiYljxe5fq629INgptH72e1M85g=; b=Q/s/lFgi2vAnQUNIfe6ltvc25/t1Io8AISgNKYUNg4p/aKRPCJB86Z6fXBLhKndFVH JcBq8nylOFBzIb4UxZt9hJe60/lfD+M6lRwYgEPCgbG7xZkn9I9RoPmLcXbrd6eRBy80 uw8eTrcNUI+58iefr83oyq1w/jSYBYOWn9MxbfqTlkTfu/yM1iG+pqFx/DnhG05brs5M OS4f6rTi471PDC9lHlztrf2XUPXo0tcPNszahut/G5C9b5lDq59ESbjVVrSc4quGtPgt nv4aS3mSuALfvOsp+O/xFk9Pp0tiZh48LXsOQkef1HkR1ySA//5DL7ofNhkRMUFrp5+U 50Jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version; bh=ZitNuTrI/UQapwn2GiYljxe5fq629INgptH72e1M85g=; b=iusRv2z5hQRt2HVPxVzS8UoyPmB0LmR40nUiltI3X/4R78LD5R08FbxaEGw1LL4yE+ 5oOXyOd+/SlYP/byyeyHZgJPjg6O7VcHTTi1ovCZcPRIy6Rgf+JFattVAw2c2fscwSxQ r4cjG0X0+zYOupPtT8uBhDB8veLfOug63TRJRpWzFaJPJeEVDtEp3xproYVzvBGeBJvG Yq7ZsFeXVhwSDLix2fK0pqqJhuWIGync7mKJRp5gcIdX6ROfd+71C5A8lcNorHjyocdA 3GmjslrPptGDhJnGyfQ+MV84nJyqx1UmbIzmWuXws07hntnLAiv4tRfuT+cWMdhlZgwP 1nVw== X-Gm-Message-State: AOAM533x5p90f/xtwj7N/Usnyi9/xFl2qIRna5drYEajqXrsBJb8Kku9 0PYeOvN4PriUzNiDeRa1uRw3SA== X-Google-Smtp-Source: ABdhPJy7CvRfPckxX4gtN7y/KZCotuF9/rGE6qrqB642Eus6Z7w124d4+V7V/4U9ixcrjHEnAQZGOQ== X-Received: by 2002:a05:6808:14c3:b0:2d9:9229:7d25 with SMTP id f3-20020a05680814c300b002d992297d25mr728807oiw.49.1646346538920; Thu, 03 Mar 2022 14:28:58 -0800 (PST) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id t11-20020a4ae40b000000b0031cc933b418sm1534025oov.40.2022.03.03.14.28.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Mar 2022 14:28:57 -0800 (PST) Date: Thu, 3 Mar 2022 14:28:46 -0800 (PST) From: Hugh Dickins X-X-Sender: hugh@ripple.anvils To: David Hildenbrand cc: Hugh Dickins , Andrew Morton , Matthew Wilcox , Nicholas Piggin , Yu Zhao , Yang Shi , Michal Hocko , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH mmotm] mm: delete __ClearPageWaiters() In-Reply-To: Message-ID: <9dda55d5-eafa-3177-2a4c-32ccb7e146e3@google.com> References: <351df0af-78f2-c20-2a6d-e5f978e5ca1@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: EE68740009 X-Stat-Signature: foac3hbkphsi88f9bryt3hnsxbgrk44a Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="Q/s/lFgi"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf04.hostedemail.com: domain of hughd@google.com designates 209.85.167.182 as permitted sender) smtp.mailfrom=hughd@google.com X-HE-Tag: 1646346539-360283 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 Thu, 3 Mar 2022, David Hildenbrand wrote: > On 03.03.22 02:56, Hugh Dickins wrote: > > The PG_waiters bit is not included in PAGE_FLAGS_CHECK_AT_FREE, and > > vmscan.c's free_unref_page_list() callers rely on that not to generate > > bad_page() alerts. So __page_cache_release() and release_pages() (and > > the presumably copy-and-pasted put_zone_device_private_or_public_page()) Hah, I'm showing my age there, or the patch's age: it's been rebranded frequently since then, with linux-next calling it free_zone_device_page(), as you kindly point out. How long before it's free_zone_device_folio()? > > are redundant and misleading to make a special point of clearing it (as > > the "__" implies, it could only safely be used on the freeing path). > > > > Delete __ClearPageWaiters(). Remark on this in one of the "possible" > > comments in wake_up_page_bit(), and delete the superfluous comments. > > > > Signed-off-by: Hugh Dickins > > --- > > We've used this since 2018, and I see Yu Zhao posted similar in 2020: > > https://lore.kernel.org/linux-mm/20200818184704.3625199-3-yuzhao@google.com/ > > I couldn't join in at that time, but think its reception was over-cautious. > > > > include/linux/page-flags.h | 2 +- > > mm/filemap.c | 22 +++++++--------------- > > mm/memremap.c | 2 -- > > mm/swap.c | 4 ---- > > 4 files changed, 8 insertions(+), 22 deletions(-) > > > > --- a/mm/filemap.c > > +++ b/mm/filemap.c > > @@ -1179,24 +1179,16 @@ static void folio_wake_bit(struct folio *folio, int bit_nr) > > } > > > > /* > > - * It is possible for other pages to have collided on the waitqueue > > - * hash, so in that case check for a page match. That prevents a long- > > - * term waiter > > + * It's possible to miss clearing waiters here, when we woke our page > > + * waiters, but the hashed waitqueue has waiters for other pages on it. > > * > > - * It is still possible to miss a case here, when we woke page waiters > > - * and removed them from the waitqueue, but there are still other > > - * page waiters. > > + * That's okay, it's a rare case. The next waker will clear it. Or, > > + * it might be left set until the page is freed: when it's masked off > > + * with others in PAGE_FLAGS_CHECK_AT_PREP, by free_pages_prepare(). > > */ > > Does that also apply to ZONE_DEVICE pages via free_zone_device_page()? I'm sure you could tell me a lot more about ZONE_DEVICE pages than I could ever tell you. But, if they don't ever reach the main page freer, then they're in the same category as other pages not freed until reboot: any clearing of left-behind PG_waiters will be done by the next waker, not by reaching free_pages_prepare(). Does that really require special mention of ZONE_DEVICE pages here? Would I do better just to remove the comment on PAGE_FLAGS_CHECK_AT_PREP being one of the clearers? (I had to do a bit of research before answering: temporarily confused about the role of PG_waiters, I worried that removing copy-and-pasted __ClearPageWaiters from free_zone_device_page() might risk gradually clogging up the hash queues with spuriously waited pages; no, nonsense, it's just a matter of how efficient the next folio_unlock() will be.) Hugh