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=-2.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 057D2C433FE for ; Thu, 16 Sep 2021 14:55:43 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 88261610D1 for ; Thu, 16 Sep 2021 14:55:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 88261610D1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id DB95C6B0071; Thu, 16 Sep 2021 10:55:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D68EB6B0072; Thu, 16 Sep 2021 10:55:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C30E66B0073; Thu, 16 Sep 2021 10:55:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0072.hostedemail.com [216.40.44.72]) by kanga.kvack.org (Postfix) with ESMTP id B061A6B0071 for ; Thu, 16 Sep 2021 10:55:41 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 5E3CA18210EA9 for ; Thu, 16 Sep 2021 14:55:41 +0000 (UTC) X-FDA: 78593735682.17.A88D890 Received: from mail-qt1-f173.google.com (mail-qt1-f173.google.com [209.85.160.173]) by imf15.hostedemail.com (Postfix) with ESMTP id 97A7AD0000A8 for ; Thu, 16 Sep 2021 14:55:40 +0000 (UTC) Received: by mail-qt1-f173.google.com with SMTP id 2so5790794qtw.1 for ; Thu, 16 Sep 2021 07:55:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=yzjiBidds/95jlWbsteDw2s2y+zSZ8imjzQuCnBCBaI=; b=Z31pcMT9ANsg+mMJt2zHhGrK0/omw8WoaeWhOTTXgviGIO3x2aGgnZhUauKxpWhtJ5 YOm3X/Mnh0el/Fczl3kbOPZNhOJN3Eg/6Gmj3ItsBNhxwseE08p+3c1OJEFVYr5XPgUr ZnFSehYY3OD3f8xIVvMaAtcX7TR2RnHp3AvQJWzJNyA6tnG/UOmAMdASfBMAfBwivGlM A1dA1iV8JWFCL5h8CKPxWCsTRHsGQXpqrXbJgguY6+ebGXK1n1NAOR8GPCJ46NPbPU8y Ao7yRCJ/OlVa0d1MrL6zs99myboBrgfiAPQcjSwQxgL7KohC+OQ4ZJiHwqdAnfqdYooT u8pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=yzjiBidds/95jlWbsteDw2s2y+zSZ8imjzQuCnBCBaI=; b=tz1RRCf6QTQTFbvDAoAVGAYjLTNIqcX9n3SBXZ6PJmiv7b7BMkALKJkARBznwiqFbY Mk5gbWrvidLYz90wDZsWaBJKWeo4tvrEZFPiUbKNzNVbzVxd3b4tW6gNSv+N2UNDia/U gQ7bXJNIMDhtD3pgwHfc7RHuKvm91Y/1HCQjERIhFWUTboj8Em6F0Fmr91cTsRcKYkeB yOUFuhlo1nlJ4ySKUgANST8kXPXcsPpU8P9aTVJUZ6ZhKq8fDdnYurFb2XgDDmAvd2cI rQrQ422UddqxT+KQ+rAssUcoJpA6aZril/lxVDeU9B3Wrx6BBPaTf44Hte9FeK0MXTU6 Hvdg== X-Gm-Message-State: AOAM531XEk/68x94TWSDY7undzHO0Ic9T20Bd6luRzNJ4jsIFSxLK9+U iDzB9JH+WNvnNLL0JxP4Ow== X-Google-Smtp-Source: ABdhPJyuYZnU0ED0rORN1nlp4m3pAhrFlfyjrakPXoVoLqrtepLNNmzUMk8zu6fmKxRmddj8pW11FA== X-Received: by 2002:ac8:5290:: with SMTP id s16mr5399475qtn.412.1631804139958; Thu, 16 Sep 2021 07:55:39 -0700 (PDT) Received: from moria.home.lan (c-73-219-103-14.hsd1.vt.comcast.net. [73.219.103.14]) by smtp.gmail.com with ESMTPSA id t26sm2395990qkm.0.2021.09.16.07.55.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Sep 2021 07:55:39 -0700 (PDT) Date: Thu, 16 Sep 2021 10:55:34 -0400 From: Kent Overstreet To: Theodore Ts'o Cc: James Bottomley , Chris Mason , Johannes Weiner , Matthew Wilcox , Linus Torvalds , "linux-mm@kvack.org" , linux-fsdevel , "linux-kernel@vger.kernel.org" , Andrew Morton , "Darrick J. Wong" , Christoph Hellwig , David Howells , "ksummit@lists.linux.dev" Subject: Re: [MAINTAINER SUMMIT] Folios as a potential Kernel/Maintainers Summit topic? Message-ID: References: <17242A0C-3613-41BB-84E4-2617A182216E@fb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Z31pcMT9; spf=pass (imf15.hostedemail.com: domain of kent.overstreet@gmail.com designates 209.85.160.173 as permitted sender) smtp.mailfrom=kent.overstreet@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Stat-Signature: k9okbdkfejbhhzkdisu73g19qu1jmk1h X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 97A7AD0000A8 X-HE-Tag: 1631804140-19037 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 Wed, Sep 15, 2021 at 04:48:55PM -0400, Theodore Ts'o wrote: > On Wed, Sep 15, 2021 at 03:15:13PM -0400, James Bottomley wrote: > > > > My reading of the email threads is that they're iterating to an actual > > conclusion (I admit, I'm surprised) ... or at least the disagreements > > are getting less. Since the merge window closed this is now a 5.16 > > thing, so there's no huge urgency to getting it resolved next week. > > My read was that it was more that people were just getting exhausted, > and not necessarily that folks were converging. (Also, Willy is > currently on vacation.) > > I'm happy to be wrong, bu the patches haven't changed since the merge > window opened, and it's not clear what *needs* to change before it can > be accepted at the next merge window. I've personally been pretty dissapointed by how the discussions went off the rails. I don't think Willy was doing the best job of explaining and advocating for his design decisions, and some of the objections of the MM people have been just crazypants. One thing I want to make clear: folios aren't about compound pages, compound pages are just the mechanism MM side for describing higher order allocations. And folios are for filesystem pages (possibly including anonymous pages going forward); they're _not_ for slab. Historically, we haven't had a clear allocator/allocatee interface or distinction in our data structures, and our taxonomy of different types of pages is also super confusing, and both of those things have been making these discussions _really_ hard - but also, I expect better of some of you people. All the bikeshedding over the naming and arguing over eventuallities that will never happen because they're just pants on head stupid makes it really hard to find people's _real_ legitimate objections when reading through these discussions. I'm probably waiting for Willy to get back from vacation so I can hear more of his rationale before doing another long recap, and I'm still waiting for Johannes to retract his NACK. One of the good things that's come out of the discussions with Johannes is we've got some good concrete ideas for cutting apart the struct page mess - Willy has done most of the initial work, after all - and I think it's now possible to work towards a clear disctinction between allocator and allocatee state and also separate data types for separate types of pages. Fundamentally, the reason struct page exists at all is because we need memory to be self describing, but a lot of stuff lives in struct page for more for convenience reasons - we have a lot of code/data sharing there that's more accidental than principled. But I'm starting to see a way forward and it's getting me pretty excited. > > > Well, the current one seems to be working (admittedly eventually, so > > achieving faster resolution next time might be good) ... but I'm sure > > you could propose alternatives ... especially in the time to resolution > > department. > > Given how long it took for DAX to converge (years and years and years > and *multiple* LSF/MM's), I'm not as optimistic that Folios is > converge and is about to be merged at the next merge window. But > again, I'm happy to be proven wrong. I hope it doesn't take _that_ long...