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.8 required=3.0 tests=BAYES_00, 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 8B645C433DB for ; Mon, 15 Mar 2021 22:29:23 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2478F64E33 for ; Mon, 15 Mar 2021 22:29:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2478F64E33 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=fromorbit.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 896886B0036; Mon, 15 Mar 2021 18:29:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8486F6B006C; Mon, 15 Mar 2021 18:29:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6E8A16B0070; Mon, 15 Mar 2021 18:29:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0034.hostedemail.com [216.40.44.34]) by kanga.kvack.org (Postfix) with ESMTP id 533856B0036 for ; Mon, 15 Mar 2021 18:29:22 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 0CE26180AD82F for ; Mon, 15 Mar 2021 22:29:22 +0000 (UTC) X-FDA: 77923550964.04.EB587CB Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by imf25.hostedemail.com (Postfix) with ESMTP id BFDC260004D6 for ; Mon, 15 Mar 2021 22:27:13 +0000 (UTC) Received: from dread.disaster.area (pa49-181-239-12.pa.nsw.optusnet.com.au [49.181.239.12]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 2A868828671; Tue, 16 Mar 2021 09:27:09 +1100 (AEDT) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1lLvg4-002xIa-IE; Tue, 16 Mar 2021 09:27:08 +1100 Date: Tue, 16 Mar 2021 09:27:08 +1100 From: Dave Chinner To: Matthew Wilcox Cc: Christoph Hellwig , Michal Hocko , "Kirill A. Shutemov" , Hugh Dickins , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v4 00/25] Page folios Message-ID: <20210315222708.GA349301@dread.disaster.area> References: <20210305041901.2396498-1-willy@infradead.org> <20210313123658.ad2dcf79a113a8619c19c33b@linux-foundation.org> <20210315115501.7rmzaan2hxsqowgq@box> <20210315190904.GB150808@infradead.org> <20210315194014.GZ2577561@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210315194014.GZ2577561@casper.infradead.org> X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.3 cv=F8MpiZpN c=1 sm=1 tr=0 cx=a_idp_d a=gO82wUwQTSpaJfP49aMSow==:117 a=gO82wUwQTSpaJfP49aMSow==:17 a=kj9zAlcOel0A:10 a=dESyimp9J3IA:10 a=7-415B0cAAAA:8 a=22_hVACOjlP6-iFW9EAA:9 a=CjuIK1q_8ugA:10 a=biEYGPWJfzWAr4FL6Ov7:22 X-Stat-Signature: uh7tt6wt7f5onftfgk1qy7aknp6zyaik X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: BFDC260004D6 Received-SPF: none (fromorbit.com>: No applicable sender policy available) receiver=imf25; identity=mailfrom; envelope-from=""; helo=mail104.syd.optusnet.com.au; client-ip=211.29.132.246 X-HE-DKIM-Result: none/none X-HE-Tag: 1615847233-616467 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 Mon, Mar 15, 2021 at 07:40:14PM +0000, Matthew Wilcox wrote: > I would agree that the conversion is both straightforward and noisy. > There are some minor things that crop up, like noticing that we get > the accounting wrong for writeback of compound pages. That's not > entirely unexpected since no filesystem supports both compound pages > and writeback today. And this is where the abstraction that the "folio" introduces is required - filesystem people don't want to have to deal with all the complexity and subtlety of compound pages when large page support is added to the page cache. As Willy says, this will be a never-ending source of data corruption bugs.... Hence from the filesystem side of things, I think this abstraction is absolutely necessary. Especially because handling buffered IO in 4kB pages really, really sucks from a performance persepctive and the sooner we have native high-order page support in the page cache the better. These days buffered IO often can't even max out a cheap NVMe SSD because of the CPU cost of per-page state management in the page cache. So the sooner we have large page support to mitigate the worst of the overhead for streaming buffered IO, the better. FWIW, like others, I'm not a fan of "folio" as a name, but I can live with it because it so jarringly different to "pages" that we're not going to confuse the two of them. But if we want a better name, my suggestion would be for a "struct cage" as in Compound pAGE.... Cheers, Dave. -- Dave Chinner david@fromorbit.com