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 X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E1B39C433ED for ; Sat, 1 May 2021 02:37:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E5EF4613BD for ; Sat, 1 May 2021 02:37:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E5EF4613BD Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D0BE36B006C; Fri, 30 Apr 2021 22:37:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CE2556B006E; Fri, 30 Apr 2021 22:37:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BA9FE6B0070; Fri, 30 Apr 2021 22:37:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0112.hostedemail.com [216.40.44.112]) by kanga.kvack.org (Postfix) with ESMTP id 9BCF26B006C for ; Fri, 30 Apr 2021 22:37:33 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 503A3181AF5C2 for ; Sat, 1 May 2021 02:37:33 +0000 (UTC) X-FDA: 78091101186.08.220DAA9 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf10.hostedemail.com (Postfix) with ESMTP id 9AE1E40002D5 for ; Sat, 1 May 2021 02:37:20 +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=6I9FPHGXTulJKTj12DEmkVmAHPYyqomkRPK519Zr5Ao=; b=PTqNAMZndlMQ01Jkl2BBForNBl po14iGZhCDGLek83XwJc9Sfda0c0+D/tpzztVHF3h91ZruvGeNzKzfuKvCkKPqJ05u97GVuZtSf4k RDZ0TREX5eEkJvieiyuayBRs9dGtn24MX4GsDCXgtPwMw1/AOjeL6rqaT93QSiT7QtQ3QP+5PiNCD ArXICoeUj2pEdxBu25LYmdKD1kU85//17P3y8T3/Y5ilqkCu7XE0Mcw3Msj4NF+dNzPJHPK5temh/ hWzguK0bFFLKf5wLi3iXpORcYkdZ2tSw0KufSTJt+Jq6s86eO/QlLc6lwT+HlsvFxC+S56kG+O+Vc bcMhFocw==; Received: from willy by casper.infradead.org with local (Exim 4.94 #2 (Red Hat Linux)) id 1lcfVH-00BqsZ-37; Sat, 01 May 2021 02:37:14 +0000 Date: Sat, 1 May 2021 03:37:11 +0100 From: Matthew Wilcox To: Nicholas Piggin Cc: Hugh Dickins , akpm@linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Linus Torvalds Subject: Re: [PATCH v8.1 00/31] Memory Folios Message-ID: <20210501023711.GP1847222@casper.infradead.org> References: <20210430180740.2707166-1-willy@infradead.org> <1619832406.8taoh84cay.astroid@bobo.none> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1619832406.8taoh84cay.astroid@bobo.none> Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=PTqNAMZn; dmarc=none; spf=none (imf10.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 9AE1E40002D5 X-Stat-Signature: hiidozobxsp34k14en91rxm8btmxehcq Received-SPF: none (infradead.org>: No applicable sender policy available) receiver=imf10; identity=mailfrom; envelope-from=""; helo=casper.infradead.org; client-ip=90.155.50.34 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1619836640-494858 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 01, 2021 at 11:32:20AM +1000, Nicholas Piggin wrote: > Excerpts from Hugh Dickins's message of May 1, 2021 4:47 am: > > On Fri, 30 Apr 2021, Matthew Wilcox (Oracle) wrote: > >> - Big renaming (thanks to peterz): > >> - PageFoo() becomes folio_foo() > >> - SetFolioFoo() becomes folio_set_foo() > >> - ClearFolioFoo() becomes folio_clear_foo() > >> - __SetFolioFoo() becomes __folio_set_foo() > >> - __ClearFolioFoo() becomes __folio_clear_foo() > >> - TestSetPageFoo() becomes folio_test_set_foo() > >> - TestClearPageFoo() becomes folio_test_clear_foo() > >> - PageHuge() is now folio_hugetlb() > > If you rename these things at the same time, can you make it clear > they're flags (folio_flag_set_foo())? The weird camel case accessors at > least make that clear (after you get to know them). > > We have a set_page_dirty(), so page_set_dirty() would be annoying. > page_flag_set_dirty() keeps the easy distinction that SetPageDirty() > provides. Maybe I should have sent more of the patches in this batch ... mark_page_accessed() becomes folio_mark_accessed() set_page_dirty() becomes folio_mark_dirty() set_page_writeback() becomes folio_start_writeback() test_clear_page_writeback() becomes __folio_end_writeback() cancel_dirty_page() becomes folio_cancel_dirty() clear_page_dirty_for_io() becomes folio_clear_dirty_for_io() lru_cache_add() becomes folio_add_lru() add_to_page_cache_lru() becomes folio_add_to_page_cache() write_one_page() becomes folio_write_one() account_page_redirty() becomes folio_account_redirty() account_page_cleaned() becomes folio_account_cleaned() So the general pattern is that folio_set_foo() and folio_clear_foo() works on the flag directly. If we do anything fancy to it, it's folio_verb_foo() where verb depends on foo. I'm not entirely comfortable with this. I'd like to stop modules from accessing folio_set_dirty() because it's just going to mess up filesystems. I just haven't thought of a good way to expose some flags and not others. Actually, looking at what filesystems actually use at the moment, it's quite a small subset: ClearPageChecked ClearPageDirty ClearPageError ClearPageFsCache __ClearPageLocked ClearPageMappedToDisk ClearPagePrivate2 ClearPagePrivate ClearPageReferenced ClearPageUptodate TestClearPageError TestClearPageFsCache TestClearPagePrivate2 TestClearPageDirty SetPageError __SetPageLocked SetPageMappedToDisk SetPagePrivate2 SetPagePrivate SetPageUptodate __SetPageUptodate TestSetPageDirty TestSetPageFsCache several of those are ... confused ... but the vast majority of page flags don't need to be exposed to filesystems. Does it make you feel better if folio_set_dirty() doesn't get exposed outside the VFS?