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,DKIM_SIGNED, DKIM_VALID,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 2E397C433F5 for ; Thu, 9 Sep 2021 22:01:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9215C6113A for ; Thu, 9 Sep 2021 22:01:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 9215C6113A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cmpxchg.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id E39736B006C; Thu, 9 Sep 2021 18:01:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DE8AF6B0072; Thu, 9 Sep 2021 18:01:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C62C76B0073; Thu, 9 Sep 2021 18:01:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0007.hostedemail.com [216.40.44.7]) by kanga.kvack.org (Postfix) with ESMTP id B41296B006C for ; Thu, 9 Sep 2021 18:01:27 -0400 (EDT) Received: from smtpin33.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 674E0182A8406 for ; Thu, 9 Sep 2021 22:01:27 +0000 (UTC) X-FDA: 78569407014.33.8C55EE6 Received: from mail-qk1-f179.google.com (mail-qk1-f179.google.com [209.85.222.179]) by imf29.hostedemail.com (Postfix) with ESMTP id E9449900013E for ; Thu, 9 Sep 2021 22:01:26 +0000 (UTC) Received: by mail-qk1-f179.google.com with SMTP id b64so3678322qkg.0 for ; Thu, 09 Sep 2021 15:01:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=QZqkF9duxuzZ+biCr/DN+cOPkA95d4hYzGir/0bZtG8=; b=n4Yox4FllS4gAcO35Nu8s/ilFPO82gh8Gm/P3mDRND5oe2rctlncS/tr0y85Fs8npP 98l5IbSFrFXrw+cwcb0zvs+hCkjsxur9V2MMDUGHT3XXfhEce73/5iWt2xplCy/3EJhh +2prmzstXNUANrptayppa1LTU1dcLX//fY9en1mSyyXXReAarLHQYYJ/9PUblzzl32wE WCEvZ5kvcljGt7MED2wLGtYBCaYZcdNBK5lTYlEhrMEneFSeEYCqWAkX/McDiRbDrXNq 5rDknVoSQRALljSxiiu1jfnqPspcTcube+E4KtX+IPf4QLINfIOzYrHc0ANRy6ZvMxWa qOTQ== 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=QZqkF9duxuzZ+biCr/DN+cOPkA95d4hYzGir/0bZtG8=; b=KIR8RMwSrZ5E+MiKDUd0HCbuf+gAEJJ2TP5YX70XtdIeSemDE8PT69w7lSXYzAwz5I P1EeVDqHzeaNjTQCc0lZvRxQrqkTCksUbsYtKN9CQgrJO7riL1Bq/0QZ3gfjjAbbF+xs UYEP4KYQNfNDPboLjUCX/1o53epYa7qqaP/mSgpzx2D/cIOvu+1lZozKLE+O/jkej4aK qh6J81Mc6qUc6I0GLA3Vt+fgqU8n4GWXZxgi+Xbydqqxy1IZJZefV8cyV5T1fyaw4Q9h HmLZI1wUcCzk5sNhCEw7yrU1DEWYAC4NE8z/ujuf/lBA4v6+VJdGExpKDfvve4/1botq JbTg== X-Gm-Message-State: AOAM530qN3JsVjaqiCN3Q0D2/+xny1hGJAnUnlKQd04u+4MyxLRrSusu PSKMlG72upJkoDzScMgPVoYp3A== X-Google-Smtp-Source: ABdhPJykIZNFvzFm3FAQRsJZQ2IJ7iZMncXFjisKzYimm3AW6YNhcKNTkQC8pRrSlAuvO/m/7fW51Q== X-Received: by 2002:a05:620a:2914:: with SMTP id m20mr5086687qkp.497.1631224886125; Thu, 09 Sep 2021 15:01:26 -0700 (PDT) Received: from localhost (cpe-98-15-154-102.hvc.res.rr.com. [98.15.154.102]) by smtp.gmail.com with ESMTPSA id s8sm1868997qta.48.2021.09.09.15.01.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Sep 2021 15:01:25 -0700 (PDT) Date: Thu, 9 Sep 2021 18:03:17 -0400 From: Johannes Weiner To: Matthew Wilcox Cc: Vlastimil Babka , Christoph Hellwig , Linus Torvalds , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Andrew Morton Subject: Re: [GIT PULL] Memory folios for v5.15 Message-ID: References: <6b01d707-3ead-015b-eb36-7e3870248a22@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: E9449900013E Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=cmpxchg-org.20150623.gappssmtp.com header.s=20150623 header.b=n4Yox4Fl; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf29.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.222.179 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org X-Stat-Signature: 7xbtr5reu67eh8k7sc6468t4ommdf3ki X-HE-Tag: 1631224886-246456 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, Sep 09, 2021 at 07:44:22PM +0100, Matthew Wilcox wrote: > On Thu, Sep 09, 2021 at 02:16:39PM -0400, Johannes Weiner wrote: > > My objection is simply to one shared abstraction for both. There is > > ample evidence from years of hands-on production experience that > > compound pages aren't the way toward scalable and maintainable larger > > page sizes from the MM side. And it's anything but obvious or > > self-evident that just because struct page worked for both roles that > > the same is true for compound pages. > > I object to this requirement. The folio work has been going on for almost > a year now, and you come in AT THE END OF THE MERGE WINDOW to ask for it > to do something entirely different from what it's supposed to be doing. > If you'd asked for this six months ago -- maybe. But now is completely > unreasonable. I asked for exactly this exactly six months ago. On March 22nd, I wrote this re: the filesystem interfacing: : So I think transitioning away from ye olde page is a great idea. I : wonder this: have we mapped out the near future of the VM enough to : say that the folio is the right abstraction? : : What does 'folio' mean when it corresponds to either a single page or : some slab-type object with no dedicated page? : : If we go through with all the churn now anyway, IMO it makes at least : sense to ditch all association and conceptual proximity to the : hardware page or collections thereof. Simply say it's some length of : memory, and keep thing-to-page translations out of the public API from : the start. I mean, is there a good reason to keep this baggage? It's not my fault you consistently dismissed and pushed past this question and then send a pull request anyway. > I don't think it's a good thing to try to do. I think that your "let's > use slab for this" idea is bonkers and doesn't work. Based on what exactly? You can't think it's that bonkers when you push for replicating slab-like grouping in the page allocator. Anyway, it was never about how larger pages will pan out in MM. It was about keeping some flexibility around the backing memory for cache entries, given that this is still an unsolved problem. This is not a crazy or unreasonable request, it's the prudent thing to do given the amount of open-ended churn and disruptiveness of your patches. It seems you're not interested in engaging in this argument. You prefer to go off on tangents and speculations about how the page allocator will work in the future, with seemingly little production experience about what does and doesn't work in real life; and at the same time dismiss the experience of people that deal with MM problems hands-on on millions of machines & thousands of workloads every day. > And I really object to you getting in the way of my patchset which > has actual real-world performance advantages So? You've gotten in the way of patches that removed unnecessary compound_head() call and would have immediately provided some of these same advantages without hurting anybody - because the folio will eventually solve them all anyway. We all balance immediate payoff against what we think will be the right thing longer term. Anyway, if you think I'm bonkers, just ignore me. If not, maybe lay off the rhetorics, engage in a good-faith discussion and actually address my feedback?