Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp555918pxb; Tue, 19 Oct 2021 08:19:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyDD8nC7by6/GyuAig+8AFP7UGJTumLMOcNIB/y8PVA+Fcyc3NzgETrdOGKAKKduaS/GGzR X-Received: by 2002:a17:906:8a45:: with SMTP id gx5mr40145358ejc.144.1634656744787; Tue, 19 Oct 2021 08:19:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634656744; cv=none; d=google.com; s=arc-20160816; b=CpjCEvxe4gxD3dA1N67nZYDihvn3GeoMKvVElGnMQM8n2OePojX2TOCzl1njZ3cdyM q6zmvjaRbDbpaLjh4mDaOc93/uaqKcdB5LEYLXaLnjYvgyPI3rpOyar0cvs5Fm0bCVVg m1K8cOCPBmC9kP7LI7aF6HVlSdmxYxQsjPaS31UA8vP57/nLG7z9yKH32arqIAmjLZi1 nSb0dkGD+abFwKCuUlGgzcLRbr78z76UNCn+WpIzaEVYvAxKtXxL+IYoZpKktcLIDosm OHtaM7y9t7dRbDhVw1Gze+hmDUqR+mj/JRHddnvtI85LbztnwuubvWhMpkAwZQVT0rPl sRUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=z2QCsj8uoI1elGSwjIcPM3flWlmV5asRjFaV2+Zm7wQ=; b=hfxZ6m9607M1BFxKpc5bPS52a7RpYcEaF8XLeXUANZ/MrgbL5ac3T1QO73EJytWcIs bnZWck+rp9+uMFYwd0it3xSVWzlqK/ooqaeIqOi+ruRTPC4jQW1v53KrZXSkTR1HVpza gSPjiXbgx70fe6lJ0MIJpCmNbdalGVMbNGBATTxiB/U50wQ8LFhnMaQCDHEBzyJS2Hp+ MtMdf5cBsScjpAtJwTnaNUdep/qSFSSMz+uTy84914ROITbA7euqome+G0sTIJ/DrcKi l7tq5KAapg9OKoUH/o7+1fnXnfisB8NUPX8ooVJfUUMR4sQHghYHv/YlJ1K3tdvuy+I/ 4GJg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=P0eGPUE0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=cmpxchg.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a20si30925743edj.558.2021.10.19.08.18.39; Tue, 19 Oct 2021 08:19:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=P0eGPUE0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=cmpxchg.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232568AbhJSPSj (ORCPT + 99 others); Tue, 19 Oct 2021 11:18:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47490 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229803AbhJSPSe (ORCPT ); Tue, 19 Oct 2021 11:18:34 -0400 Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6863CC06161C for ; Tue, 19 Oct 2021 08:16:21 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id y10so232446qkp.9 for ; Tue, 19 Oct 2021 08:16:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=z2QCsj8uoI1elGSwjIcPM3flWlmV5asRjFaV2+Zm7wQ=; b=P0eGPUE0ED5s2q2cgVj1MBGSU0NFueMDTHHmFRDzaMGveNnY7eva5aqT9YKQ4ywom6 zIBle47EmTwcAGH0xgKkEuTEMYd+gvhyrjK32+CGng9rdAaUEaGnDlgvj43WQBoC1hUg Fp039gNDJQjIHUPuAM6nPkJCi5ezTCcmovk4gOXKIV8ryUuMAN1CxV/T79DoYzhFDQYg kbEdvYeuB4IMGQ+vpKB+O6oyDQ80i5ffweK5/54+rpeYMCPUuqWkQM7qDnXrsPY3o+SZ tr/dVhtB+oqSceg4VpqqguL/+ocqLY1sTtqlBroX8n/oiI+dlCsxIaaWmMdnwA4tin94 r+dQ== 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=z2QCsj8uoI1elGSwjIcPM3flWlmV5asRjFaV2+Zm7wQ=; b=6zQoOlgBqjhbgDEYpkte8afuafhNyTGyANNiRdkyqg9ev0YLvwlgUmSjrS+epramSh BOR3kAAObzJR9DjINTRfjrZWRT1BwuRtCESbJgZh6Uzs8ZiE+QV+vGSkptR/Bd/6gJa/ 4OwTkET2h60Mxg5oicV6SweBMQkkMT1XR9akcCWS4a2FH12jUpSG3aPlGyCQt5H8k2ER PxYeYq+GYcab93zRzcCP4F6Kblc4aEIQo0ZafZMytRFpvM1VacyXxKejnLz2YMSTanw/ ud501cYoZuoEdG7rLVYte/7ZNNPXt3qLX1RXNnleRGadm1UjOUpcJxEHG8xGeaGvKVYC gWrQ== X-Gm-Message-State: AOAM530GxKG88lkGY+kOa7vwU5VhljXos9MOEWrfI8V8Ag4EjAuBvwvh 5WNMS4tcNsQzYKVIJ/pR2SwDhrT9Mtm3gQ== X-Received: by 2002:a05:620a:45a4:: with SMTP id bp36mr457879qkb.51.1634656580587; Tue, 19 Oct 2021 08:16:20 -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 z6sm734425qtj.90.2021.10.19.08.16.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Oct 2021 08:16:19 -0700 (PDT) Date: Tue, 19 Oct 2021 11:16:18 -0400 From: Johannes Weiner To: "Kirill A. Shutemov" Cc: Matthew Wilcox , Kent Overstreet , Linus Torvalds , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Andrew Morton , "Darrick J. Wong" , Christoph Hellwig , David Howells , Hugh Dickins Subject: Re: Folios for 5.15 request - Was: re: Folio discussion recap - Message-ID: References: <20211018231627.kqrnalsi74bgpoxu@box.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211018231627.kqrnalsi74bgpoxu@box.shutemov.name> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 19, 2021 at 02:16:27AM +0300, Kirill A. Shutemov wrote: > On Mon, Oct 18, 2021 at 05:56:34PM -0400, Johannes Weiner wrote: > > > I don't think there will ever be consensus as long as you don't take > > > the concerns of other MM developers seriously. On Friday's call, several > > > people working on using large pages for anon memory told you that using > > > folios for anon memory would make their lives easier, and you didn't care. > > > > Nope, one person claimed that it would help, and I asked how. Not > > because I'm against typesafety, but because I wanted to know if there > > is an aspect in there that would specifically benefit from a shared > > folio type. I don't remember there being one, and I'm not against type > > safety for anon pages. > > > > What several people *did* say at this meeting was whether you could > > drop the anon stuff for now until we have consensus. > > My read on the meeting was that most of people had nothing against anon > stuff, but asked if Willy could drop anon parts to get past your > objections to move forward. > > You was the only person who was vocal against including anon pars. (Hugh > nodded to some of your points, but I don't really know his position on > folios in general and anon stuff in particular). Nobody likes to be the crazy person on the soapbox, so I asked Hugh in private a few weeks back. Quoting him, with permission: : To the first and second order of approximation, you have been : speaking for me: but in a much more informed and constructive and : coherent and rational way than I would have managed myself. It's a broad and open-ended proposal with far reaching consequences, and not everybody has the time (or foolhardiness) to engage on that. I wouldn't count silence as approval - just like I don't see approval as a sign that a person took a hard look at all the implications. My only effort from the start has been working out unanswered questions in this proposal: Are compound pages the reliable, scalable, and memory-efficient way to do bigger page sizes? What's the scope of remaining tailpages where typesafety will continue to lack? How do we implement code and properties shared by folios and non-folio types (like mmap/fault code for folio and network and driver pages)? There are no satisfying answers to any of these questions, but that also isn't very surprising: it's a huge scope. Lack of answers isn't failure, it's just a sign that the step size is too large and too dependent on a speculative future. It would have been great to whittle things down to a more incremental and concrete first step, which would have allowed us to keep testing the project against reality as we go through all the myriad of uses and cornercases of struct page that no single person can keep straight in their head. I'm grateful for the struct slab spinoff, I think it's exactly all of the above. I'm in full support of it and have dedicated time, effort and patches to help work out kinks that immediately and inevitably surfaced around the slab<->page boundary. I only hoped we could do the same for file pages first, learn from that, and then do anon pages; if they come out looking the same in the process, a unified folio would be a great trailing refactoring step. But alas here we are months later at the same impasse with the same open questions, and still talking in circles about speculative code. I don't have more time to invest into this, and I'm tired of the vitriol and ad-hominems both in public and in private channels. I'm not really sure how to exit this. The reasons for my NAK are still there. But I will no longer argue or stand in the way of the patches.