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 49CB5C636C9 for ; Fri, 16 Jul 2021 03:19:16 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EFAC5613E3 for ; Fri, 16 Jul 2021 03:19:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EFAC5613E3 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 149878D00F4; Thu, 15 Jul 2021 23:19:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0FA468D00EC; Thu, 15 Jul 2021 23:19:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F2BC18D00F4; Thu, 15 Jul 2021 23:19:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0165.hostedemail.com [216.40.44.165]) by kanga.kvack.org (Postfix) with ESMTP id CB1458D00EC for ; Thu, 15 Jul 2021 23:19:15 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id A3015267F4 for ; Fri, 16 Jul 2021 03:19:14 +0000 (UTC) X-FDA: 78366995028.13.4B626F1 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf17.hostedemail.com (Postfix) with ESMTP id 2BCF7F00215E for ; Fri, 16 Jul 2021 03:19:14 +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=YJuHEwapSltASFpILWUNzMl5SPEKG8/2ANXYoq2HkBU=; b=h36gNtuVFuvS9UeGvV/j+hrId+ zvo+adnj2okPAYN6dPtpp21ecuG4iZfLScgRZhAj5Iq3KIzBiVvrn7erZeSxMjlryTjnDDxslDzVx fZoyInAnyLJmI89qOVsdRd7jgCmjBac1c9ttT0NHDae591fNilMxvrvhKT0EQk6k0sENCFevC9vR1 OACfEf2gjmL/vyRqD5rRIKSZbuwSpmiyO85uAXiMPujT84sJss1sFbH4LS25xUQXsuQGtsWCWbamA zNrOkREMhCXcv7FD08OiK3nHLJc6/LGFEmX5bGwwOi46dv83+po2AwNvTRySdYNxVTjOybtPlMmZ+ Bm+gJm+w==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1m4EMl-0046Aa-2a; Fri, 16 Jul 2021 03:18:32 +0000 Date: Fri, 16 Jul 2021 04:18:19 +0100 From: Matthew Wilcox To: "Darrick J. Wong" Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v14 101/138] iomap: Convert iomap_page_mkwrite to use a folio Message-ID: References: <20210715033704.692967-1-willy@infradead.org> <20210715033704.692967-102-willy@infradead.org> <20210715214106.GL22357@magnolia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210715214106.GL22357@magnolia> Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=h36gNtuV; spf=none (imf17.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-Stat-Signature: yf7scs6rxayghmth6qz7hb57rprnnks3 X-Rspamd-Queue-Id: 2BCF7F00215E X-Rspamd-Server: rspam01 X-HE-Tag: 1626405554-27303 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, Jul 15, 2021 at 02:41:06PM -0700, Darrick J. Wong wrote: > > @@ -975,33 +975,33 @@ iomap_page_mkwrite_actor(struct inode *inode, loff_t pos, loff_t length, > > > > vm_fault_t iomap_page_mkwrite(struct vm_fault *vmf, const struct iomap_ops *ops) > > { > > - struct page *page = vmf->page; > > + struct folio *folio = page_folio(vmf->page); > > If before the page fault the folio was a compound 2M page, will the > memory manager will have split it into 4k pages before passing it to us? > > That's a roundabout way of asking if we should expect folio_mkwrite at > some point. ;) Faults are tricky. For ->fault, we need to know the precise page which the fault occurred on (this detail is handled for you by filemap_fault()). For mkwrite(), the page will not be split, so it's going to be a matter of just marking the entire compound page as dirty (in the head page) and making sure the filesystem is able to write back the entire folio. Yes, there's going to be some write amplification here. I believe this will turn out to be a worthwhile tradeoff. If I'm wrong, we can implement some kind of split-on-fault.