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.5 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 B7762C433EF for ; Thu, 9 Sep 2021 18:45:26 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B45F361100 for ; Thu, 9 Sep 2021 18:45:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org B45F361100 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 0BD5E900002; Thu, 9 Sep 2021 14:45:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 06CFE6B0072; Thu, 9 Sep 2021 14:45:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E9E01900002; Thu, 9 Sep 2021 14:45:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id DC60B6B006C for ; Thu, 9 Sep 2021 14:45:24 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 9CC1618F68 for ; Thu, 9 Sep 2021 18:45:24 +0000 (UTC) X-FDA: 78568912968.25.0E09554 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf23.hostedemail.com (Postfix) with ESMTP id 0CCCA90000AC for ; Thu, 9 Sep 2021 18:45:23 +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-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=7cIe376GgS7Aa1qahSeo56O31ILie9slE4Ah8Ipra0Y=; b=isb8aKhsQKU9aodtEFHcPo7q+Z 1Nz6ODr+wnNeD8tqFqpeXKTvLRgFv+5BQgvx9iSfVaTGxb9av/YCRKFbBmX9n2NZU2cwtag7ol6Lw SgXaHyt/SGoDFon3xW2co6a60bgibv0hfVX5O8nmJokeW3SdWM83X9LZSERTPciu1OL5hEzh9HPlK F8RPUS99ce8oAHkeEkjKwN7yIdoosW0p3Xb3LsfSJiw1P9M9is4mkz/Wk1xmzT4G4gj7CfbhE0Rjh Qa6kQ6E0tTaIpPMpKbvYjlQzX8XMRONPmrOXUMN4OPbsOodB0lv3y2jWn/c6L/ZzbeFnWyFEtCN87 K5TrPHxQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mOP26-00AHI7-QI; Thu, 09 Sep 2021 18:44:33 +0000 Date: Thu, 9 Sep 2021 19:44:22 +0100 From: Matthew Wilcox To: Johannes Weiner 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: Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=isb8aKhs; spf=none (imf23.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: 0CCCA90000AC X-Stat-Signature: tbc1jdyomuuueajfkzpqs89jt5iym9xq X-HE-Tag: 1631213123-504517 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 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 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. And I really object to you getting in the way of my patchset which has actual real-world performance advantages in order to whine about how bad the type system is in Linux without doing anything to help with it. Do something. Or stop standing in the way. Either works for me.