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 CECD1C4320E for ; Wed, 1 Sep 2021 11:42:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 56D016108E for ; Wed, 1 Sep 2021 11:42:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 56D016108E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ubuntu.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id D1BCB6B006C; Wed, 1 Sep 2021 07:42:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CCAA06B0071; Wed, 1 Sep 2021 07:42:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BB8996B0072; Wed, 1 Sep 2021 07:42:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0248.hostedemail.com [216.40.44.248]) by kanga.kvack.org (Postfix) with ESMTP id AD7096B006C for ; Wed, 1 Sep 2021 07:42:28 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 6DC718249980 for ; Wed, 1 Sep 2021 11:42:28 +0000 (UTC) X-FDA: 78538816776.18.B28B95C Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf11.hostedemail.com (Postfix) with ESMTP id ECF3AF0000A8 for ; Wed, 1 Sep 2021 11:42:27 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 4007761056; Wed, 1 Sep 2021 11:42:24 +0000 (UTC) Date: Wed, 1 Sep 2021 13:42:22 +0200 From: Christian Brauner To: David Howells Cc: torvalds@linux-foundation.org, Andrew Morton , Johannes Weiner , Matthew Wilcox , Theodore Ts'o , Christoph Hellwig , Alexander Viro , Vlastimil Babka , Rasmus Villemoes , "Darrick J. Wong" , Dan Williams , Jeff Layton , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: Folios: Can we resolve this please? Message-ID: <20210901114222.fm6enxi66nkynwc4@wittgenstein> References: <3285174.1630448147@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <3285174.1630448147@warthog.procyon.org.uk> X-Rspamd-Queue-Id: ECF3AF0000A8 Authentication-Results: imf11.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf11.hostedemail.com: domain of "SRS0=mVig=NX=ubuntu.com=christian.brauner@kernel.org" designates 198.145.29.99 as permitted sender) smtp.mailfrom="SRS0=mVig=NX=ubuntu.com=christian.brauner@kernel.org" X-Rspamd-Server: rspam01 X-Stat-Signature: oirmkcataxdwihweqqcmw6n3acf1hegj X-HE-Tag: 1630496547-856351 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 Tue, Aug 31, 2021 at 11:15:47PM +0100, David Howells wrote: > Hi Linus, Andrew, Johannes, > > Can we come to a quick resolution on folios? I'd really like this to be > solved in this merge window if at all possible as I (and others) have stuff > that will depend on and will conflict with Willy's folio work. It would be > great to get this sorted one way or another. > > As I see it, there are three issues, I think, and I think they kind of go like > this: > > (1) Johannes wants to get away from pages being used as the unit of memory > currency and thinks that folios aren't helpful in this regard[1]. There > seems to be some disagreement about where this is heading. > > (2) Linus isn't entirely keen on Willy's approach[2], with a bottom up > approach hiding the page objects behind a new type from the pov of the > filesystem, but would rather see the page struct stay the main API type > and the changes be hidden transparently inside of that. > > I think from what Linus said, he may be in favour (if that's not too > strong a word) of using a new type to make sure we don't miss the > necessary changes[3]. > > (3) Linus isn't in favour of the name 'folio' for the new type[2]. Various > names have been bandied around and Linus seems okay with "pageset"[4], > though it's already in minor(-ish) use[5][6]. Willy has an alternate > patchset with "folio" changed to "pageset"[7]. > > With regard to (1), I think the folio concept could be used in future to hide > at least some of the paginess from filesystems. > > With regard to (2), I think a top-down approach won't work until and unless we > wrap all accesses to struct page by filesystems (and device drivers) in > wrapper functions - we need to stop filesystems fiddling with page internals > because what page internals may mean may change. > > With regard to (3), I'm personally fine with the name "folio", as are other > people[8][9][10][11], but I could also live with a conversion to "pageset". > > Is it possible to take the folios patchset as-is and just live with the name, > or just take Willy's rename-job (although it hasn't had linux-next soak time > yet)? Or is the approach fundamentally flawed and in need of redoing? I can't speak to the deep technical mm problems but from a pure "user" perspective, I think this is a genuinely good patchset which simplifies and unifies a good set of things. Sure, it is a lot of changes. But the fact that a range of people have ported their patchsets to make use of the new folio api is a rather good sign imho. If I saw a huge changeset like this coming in that I don't believe is worth it I wouldn't port my patches to it. So I think that expresses a decent amount of practial confidence in the changes and that the conversion has been done in a way that is tasteful. Of course there are other ways of doing it; there always are. I don't have yet another clever name to propose. The "folio" prefix forms a very natural api over a wide range of helpers such as folio_memcg_kmem(), folio_file_mapping() et al. I found the other suggestions to be rather clunky compared to that. And compsci and science in general thrives on piling on additional meaning on existing concepts. Christian