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=-8.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=ham 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 C5B94C433DB for ; Mon, 22 Mar 2021 01:19:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6F5DB61937 for ; Mon, 22 Mar 2021 01:19:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6F5DB61937 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 A76516B0036; Sun, 21 Mar 2021 21:19:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A264E6B006C; Sun, 21 Mar 2021 21:19:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8C7626B0070; Sun, 21 Mar 2021 21:19:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0049.hostedemail.com [216.40.44.49]) by kanga.kvack.org (Postfix) with ESMTP id 72FE06B0036 for ; Sun, 21 Mar 2021 21:19:33 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 32C8F12D8 for ; Mon, 22 Mar 2021 01:19:33 +0000 (UTC) X-FDA: 77945752626.10.D77E016 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf12.hostedemail.com (Postfix) with ESMTP id 454CE132 for ; Mon, 22 Mar 2021 01:19:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Content-Type:MIME-Version:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:In-Reply-To:References; bh=s8mDUf3Enn/FoZ62WD9h0qniVO0+W7pXAxP0P9xb0xM=; b=bxWPyq42IIMurRO11ZjV9eQYcx hw+m+fcvKHIt7z61WaXAUpxnHNNAqVcDkgkFHsZ74MR2l2ys91uH/AAFMP5jKj5YGDCVyFTnC4bgK Nd/yJFVsClbNzTYscrXYMvMAAV0/aud1pem6jjezn/Dbza3jHTlhKbckGoSOPEfV5pEEFLc59sMrh 7Imx66t68wq5fy76XBNnk+Z+9ttFqm8XB99EtXkRBybM58TJvjwQbByEILiJ4Sb1mJqiK7dw6KDtM sckaYGz/97JGysnltywARUNTZENU7kNg/odcn5yfJGw2aJgC9avWxH8mZemRWm6MDAyEXRr8EoTPH DG9GjA7g==; Received: from willy by casper.infradead.org with local (Exim 4.94 #2 (Red Hat Linux)) id 1lO9Dn-007nXh-Mc; Mon, 22 Mar 2021 01:19:23 +0000 Date: Mon, 22 Mar 2021 01:19:07 +0000 From: Matthew Wilcox To: linux-mm@kvack.org Cc: linux-fsdevel@vger.kernel.org Subject: set_page_dirty variants Message-ID: <20210322011907.GB1719932@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 454CE132 X-Stat-Signature: oxtbdj1f49gqymr3gzysddc4gboqxn5j Received-SPF: none (infradead.org>: No applicable sender policy available) receiver=imf12; identity=mailfrom; envelope-from=""; helo=casper.infradead.org; client-ip=90.155.50.34 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616375972-549843 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: We currently have three near-identical implementations of the set_page_dirty address_space op: __set_page_dirty_no_writeback added 2007 by Ken Chen (767193253bba) (return value fixed by Bob Liu in 2011 (c3f0da631539)) anon_set_page_dirty added 2009 by Peter Zijlstra (d3a9262e59f7) noop_set_page_dirty added 2018 by Dan Williams (f44c77630d26) I persuaded Mike to remove hugetlbfs_set_page_dirty and Daniel Vetter to remove fb_deferred_io_set_page_dirty (in -next) so we're down from five to three. I'd like to get it down to zero. After all, the !mapping case in set_page_dirty() is exactly what we want. So is there a problem with doing this? +++ b/mm/page-writeback.c @@ -2562 +2562 @@ int set_page_dirty(struct page *page) - if (likely(mapping)) { + if (likely(mapping && mapping_can_writeback(mapping))) { But then I noticed that we have both mapping_can_writeback() and mapping_use_writeback_tags(), and I'm no longer sure which one to use. Also, why don't we mirror the results of inode_to_bdi(mapping->host)->capabilities & BDI_CAP_WRITEBACK into a mapping->flags & AS_something bit? We have lots available, and inode_to_bdi seems relatively complicated to be a static inline that gets evaluated every time we call pagecache_get_page(FGP_CREAT | FGP_WRITE).