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.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 A3986C433F5 for ; Wed, 22 Sep 2021 19:56:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 43C8261050 for ; Wed, 22 Sep 2021 19:56:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 43C8261050 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id A2D6C900003; Wed, 22 Sep 2021 15:56:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9DCBA900002; Wed, 22 Sep 2021 15:56:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8CB0D900003; Wed, 22 Sep 2021 15:56:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0125.hostedemail.com [216.40.44.125]) by kanga.kvack.org (Postfix) with ESMTP id 7F6FB900002 for ; Wed, 22 Sep 2021 15:56:31 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 3518282499B9 for ; Wed, 22 Sep 2021 19:56:31 +0000 (UTC) X-FDA: 78616266582.26.39EB67A Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf04.hostedemail.com (Postfix) with ESMTP id A109C50000AD for ; Wed, 22 Sep 2021 19:56:30 +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-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=UFM1KH+zbmE6JPHyyEk8OWK9O00VbDZsAf/P5r/PwVA=; b=sjUW1wCfS/qcUgj52Pj6I8ML4e nti+AqFV5uc4gcg3ZIS4UomxPfwQLkYv6gUZJPsprODAOa9sj/DfTZeZjGuhUx4t9sms/ZlLGNJ/U hf/SIOlOYcbUbZnco1mlRwaYp1ZOrEK5NmzkmLbjCVv1h0tyOkYal1v62Kiq0EqYofRyy7ASSxEw2 GcOvnOyN1vtscgV9r0xs0bVOU5mbl7Ciu1cK0/Jhi/Bu9k2F6YVVbeExrJifv0piQDzM8YOa4Cdx8 uDW+cz7MB4O0dcAVmzfmX9+bTjNq95nlnrG6ilIOfy6MZ2/Dnl4ANCe3aXZBw09fNXfkOaxNFq1DJ RMx+KGJw==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mT8Jn-0055RS-4s; Wed, 22 Sep 2021 19:54:31 +0000 Date: Wed, 22 Sep 2021 20:54:11 +0100 From: Matthew Wilcox To: Chris Mason Cc: Kent Overstreet , Johannes Weiner , Linus Torvalds , "linux-mm@kvack.org" , linux-fsdevel , "linux-kernel@vger.kernel.org" , Andrew Morton , "Darrick J. Wong" , Christoph Hellwig , David Howells Subject: Re: Folios for 5.15 request - Was: re: Folio discussion recap - Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=sjUW1wCf; spf=none (imf04.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-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: A109C50000AD X-Stat-Signature: rq3oqw6moo6dr6cn9ne3ekirf549wkrj X-HE-Tag: 1632340590-228136 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Sep 22, 2021 at 04:56:16PM +0000, Chris Mason wrote: >=20 > > On Sep 22, 2021, at 12:26 PM, Matthew Wilcox wr= ote: > >=20 > > On Wed, Sep 22, 2021 at 11:46:04AM -0400, Kent Overstreet wrote: > >> On Wed, Sep 22, 2021 at 11:08:58AM -0400, Johannes Weiner wrote: > >>> On Tue, Sep 21, 2021 at 05:22:54PM -0400, Kent Overstreet wrote: > >>>> - it's become apparent that there haven't been any real objections= to the code > >>>> that was queued up for 5.15. There _are_ very real discussions a= nd points of > >>>> contention still to be decided and resolved for the work beyond = file backed > >>>> pages, but those discussions were what derailed the more modest,= and more > >>>> badly needed, work that affects everyone in filesystem land > >>>=20 > >>> Unfortunately, I think this is a result of me wanting to discuss a = way > >>> forward rather than a way back. > >>>=20 > >>> To clarify: I do very much object to the code as currently queued u= p, > >>> and not just to a vague future direction. > >>>=20 > >>> The patches add and convert a lot of complicated code to provision = for > >>> a future we do not agree on. The indirections it adds, and the hybr= id > >>> state it leaves the tree in, make it directly more difficult to wor= k > >>> with and understand the MM code base. Stuff that isn't needed for > >>> exposing folios to the filesystems. > >>>=20 > >>> As Willy has repeatedly expressed a take-it-or-leave-it attitude in > >>> response to my feedback, I'm not excited about merging this now and > >>> potentially leaving quite a bit of cleanup work to others if the > >>> downstream discussion don't go to his liking. > >=20 > > We're at a take-it-or-leave-it point for this pull request. The time > > for discussion was *MONTHS* ago. > >=20 >=20 > I=E2=80=99ll admit I=E2=80=99m not impartial, but my fundamental goal i= s moving the patches forward. Given folios will need long term maintenan= ce, engagement, and iteration throughout mm/, take-it-or-leave-it pulls s= eem like a recipe for future conflict, and more importantly, bugs. >=20 > I=E2=80=99d much rather work it out now. That's the nature of a pull request. It's binary -- either it's pulled o= r it's rejected. Well, except that Linus has opted for silence, leaving me in limbo. I have no idea what he's thinking. I don't know if he agrees with Johannes. I don't know what needs to change for Linus to like this series enough to pull it (either now or in the 5.16 merge window). And that makes me frustrated. This is over a year of work from me and others, and it's being held up over concerns which seem to me to be entirely insubstantial (the name "folio"? really? and even my change to use "pageset" was met with silence from Linus.) I agree with Kent & Johannes that struct page is a mess. I agree that cleaning it up will bring many benefits. I've even started a design document here: https://kernelnewbies.org/MemoryTypes I do see some advantages to splitting out anon memory descriptors from file memory descriptors, but there is also plenty of code which handles both types in the same way. I see the requests to continue to use struct page to mean a "memory descriptor which is either anon or file", but I really think that's the wrong approach. A struct page should represent /a page/ of memory. Otherwise we're just confusing people. I know it's a confusion we've had since compound pages were introduced, what, 25+ years ago, but that expediency has overstayed its welcome. The continued silence from Linus is really driving me to despair. I'm sorry I've been so curt with some of the requests. I really am willing to change things; I wasn't planning on doing anything with slab until Kent prodded me to do it. But equally, I strongly believe that everything I've done here is a step towards the things that everybody wants, and I'm frustrated that it's being perceived as a step away, or even to the side of what people want. So ... if any of you have Linus' ear. Maybe you're at a conference with him later this week. Please, just get him to tell me what I need to do to make him happy with this patchset.