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 B5B9DC433EF for ; Fri, 11 Mar 2022 22:54:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230016AbiCKWzD (ORCPT ); Fri, 11 Mar 2022 17:55:03 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34728 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229940AbiCKWyk (ORCPT ); Fri, 11 Mar 2022 17:54:40 -0500 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 553E5EACA6 for ; Fri, 11 Mar 2022 14:28:25 -0800 (PST) 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=wWQbXRbezK3NRtMtSi3ATf+Wd1xnlwmrtyeo6SDza4g=; b=cscqcGcM1lLDTv+e62zL2JJ8/l cjyGSld5RQSrMMzrK/JdnjJVU6L6l3yRd7ZL235Cc91w7HF9VEiyo4+RBu+yHRkTGKLuf/UeNmFtw h1kA3VfBe0IKLd04WWWViDYGEDY0I/TyWjwZJMsdrLandRQ7XdxXsaCxuDDSS7AKWnD/omYWWKJOi swpIjr2rGRmLSPzOy1kjVyeUJDS45VVrW3b4iD2D/PWN59WP7YeZh1EOi0EeuMXi9vBMMsUCpsoq4 EAtBAJK/RHJagf/UtFneS5/33r4uOUE2vzUElJUvYzx+1JhK1siaKTTmGhzSH/ThdHQmeVoZv4s3O MnDl4fmw==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nSmXf-001usC-TV; Fri, 11 Mar 2022 21:11:19 +0000 Date: Fri, 11 Mar 2022 21:11:19 +0000 From: Matthew Wilcox To: David Hildenbrand Cc: Linus Torvalds , Linux Kernel Mailing List , Andrew Morton , Hugh Dickins , David Rientjes , Shakeel Butt , John Hubbard , Jason Gunthorpe , Mike Kravetz , Mike Rapoport , Yang Shi , "Kirill A . Shutemov" , Vlastimil Babka , Jann Horn , Michal Hocko , Nadav Amit , Rik van Riel , Roman Gushchin , Andrea Arcangeli , Peter Xu , Donald Dutile , Christoph Hellwig , Oleg Nesterov , Jan Kara , Liang Zhang , Pedro Gomes , Oded Gabbay , Linux-MM Subject: Re: [PATCH v1 10/15] mm/page-flags: reuse PG_slab as PG_anon_exclusive for PageAnon() pages Message-ID: References: <20220308141437.144919-1-david@redhat.com> <20220308141437.144919-11-david@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 11, 2022 at 08:36:37PM +0100, David Hildenbrand wrote: > I used PG_error before, but felt like using a bit that is never ever > valid to be set/cleared/checked on a subpage would be even a better fit: > > Note the: > > PAGEFLAG(Waiters, waiters, PF_ONLY_HEAD) __CLEARPAGEFLAG(Waiters, waiters, PF_ONLY_HEAD) > > whereby PF_ONLY_HEAD translates to: > > "for compound page, callers only ever operate on the head page." > > > I can just switch to PG_error, but for the second subpage, PG_waiters > should be just fine (unless I am missing something important). I think you're missing something important that almost everybody misses when looking at this code (including me). PF_ANY flags can be set on individual pages. PF_HEAD means "we automatically redirect all operations to the head page". PF_ONLY_HEAD means "If you try to call this on a tail page, we BUG". PF_NO_TAIL means "If you try to read this flag on a tail page, we'll look at the head page instead, but if you try to set/clear this flag on a tail page, we BUG" PF_NO_COMPOUND means "We BUG() if you call this on a compound page" So really, you can reuse any flag as PF_SECOND that isn't PF_ANY. No, that's not what the documentation currently says. It should be. I had a patch to reword it at some point, but I guess it got lost. The current documentation reads like "We replicate the flag currently set on the head page to all tail pages", but that just isn't what the code does.