Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp2137937pxb; Fri, 17 Sep 2021 03:09:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyanMwk3UBxebaCf6WBg0hYekfdukNsyeSVYdnkL81JP5W0CtGhtPJ53PuXy9LHuCckBn7D X-Received: by 2002:a05:6402:cbb:: with SMTP id cn27mr11837799edb.5.1631873389818; Fri, 17 Sep 2021 03:09:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631873389; cv=none; d=google.com; s=arc-20160816; b=qoI3oZpstJP12AEPRB5sj29q3kJLjYMq8ZXAZ1OypoPEari3hVSUV1Px+rkNw5YmOA Gn0tPxlwrAhWkT8Q/aP2ET0XFx7l74ceV+HRhTtinnRY7NW09fBuUQX8x2MtfROcUkza cNqextegp5j1NTlkQfI4CConW2+V7xEShA1IgD++8m45gWkwPnrsGmJKdpQJ86TzTER5 Lplb8yrCmk4eiVZ4jMStR2JJWbqLA9D1/ZJOZSYd6DY/dchZ+b94wSNEwcyxOB4DzpgW 2pPhiy6mG4GhEyOwjQ8zfY/wc1wTOM8cvm7GdupgCOhGEh6v/3MK7/R5RmqIT1q7SIDd e32g== 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-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=vlqqF3aGQ2eJaPBdv6UL0dunhLy//KiuFrPkTBRgncY=; b=sIfzGYqNaKYJzkcIVrhhLnlPPnbEoXDXDWUUsya04DqIYWf58RbaOVKyDw7jq5K4Ic Kz89hhe+lVrUMyemDkAXeyIE2VA77TXjRTHiS056GoVbTF2Se4Rkk03eddbKwS4TUmGV B+q68qnLtD0ySRuB/a0ov/BFn4577sKMdwblQgCZ9KX5tNJdiGqhQigTshfsI4FCBsR4 08L4eEZAapJ1qVGaO7yL837Y6LpSSDQgC2jGdiPtEQ44XfzGYXBjpBiSLy14f7mJfesq PO+9oIG/vAt+f/bJBTaKYLqsbtEAUMwwRWvTSASPoILG1Ww8oDe9QM5U83tWjeQq0xrg 7aFQ== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c28si6621608ejj.414.2021.09.17.03.09.26; Fri, 17 Sep 2021 03:09:49 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242447AbhIQBoi (ORCPT + 99 others); Thu, 16 Sep 2021 21:44:38 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:45160 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S242430AbhIQBo0 (ORCPT ); Thu, 16 Sep 2021 21:44:26 -0400 Received: from cwcc.thunk.org (pool-72-74-133-215.bstnma.fios.verizon.net [72.74.133.215]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 18H1gLWH003228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 Sep 2021 21:42:22 -0400 Received: by cwcc.thunk.org (Postfix, from userid 15806) id 4DEA515C0098; Thu, 16 Sep 2021 21:42:21 -0400 (EDT) Date: Thu, 16 Sep 2021 21:42:21 -0400 From: "Theodore Ts'o" To: Kent Overstreet 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> <33a2000f56d51284e2df0cfcd704e93977684b59.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 16, 2021 at 04:16:27PM -0400, Kent Overstreet wrote: > So I think we're still trying to answer the "what exactly is a folio" > question.... > However, Johannes has been pointing out that it's a real open > question as to whether anonymous pages should be folios! Willy's > current code seems to leave things in a somewhat intermediate state > - some mm/ code treats anonymous pages as folios, but it's not clear > to me how much.... Kent, you raise some good questions, and good points. However, it seems to me that one of the other sources of the disagreement is the question of whether this question needs to be answered at all before the Folios patch can get merged. We could engage in a process such as what Chris Mason has suggested, with a more formal design doc, with stakeholders who have to review, comment, and explicitly give their LGTM's. We do that sort of thing quite often at Google (and probably at many other companies), so it's a familiar approach. That would be a fine way of trying to come to a formal agreement on that question. What comes to my mind, though, is the quote, originally made by Linus, "Linux is evolution, not Intelligent Design". Greg K-H requoted Linus in his 2006 Ottawa Linux Symposium[1], “Myths, Lies, and Truths about the Linux Kernel”, and further claimed, "The kernel is not developed with big design documents, feature requests and so on." [1] http://www.kroah.com/log/linux/ols_2006_keynote.html Of course, that was 15 years ago, and things have gotten a lot more complex. And when things get more complex, a certain amount of agreement ahead of time between developers, memorialized by Design Docs, does become more and more inevitable. The source of friction, then is how *much* pre-design and consensus is needed in a particular case. After all, as you said: ".... folios are a start on cutting up the unholy mess that is struct page into separate data types. In struct page, we have a big nested union of structs, for different types of pages." So one could argue that folio makes things better. It's not an 100% solution, and perhaps it's unfortunate that it leaves things "in a somewhat intermediate state". But if it's better than what we currently have, perhaps we should land this patch set, and if we need to make further evolutionary changes, is that really such a tragedy? After all, we've never guaranteed stable API's (another thing which Greg foot-stomped in his 2006 keynote). Maybe after we live with folios, we'll learn more about the benefits and downsides, we can make further changes --- evolution, as we might say. Quoting further from Greg K-H: "The Linux USB code has been rewritten at least three times. We've done this over time in order to handle things that we didn't originally need to handle, like high speed devices, and just because we learned the problems of our first design, and to fix bugs and security issues. Each time we made changes in our api, we updated all of the kernel drivers that used the apis, so nothing would break. And we deleted the old functions as they were no longer needed, and did things wrong. Because of this, Linux now has the fastest USB bus speeds when you test out all of the different operating systems....."[1] (And it's not just the USB subsystem that has been rewritten three times; our networking stack has been rewritten at least 3 times as well.) It seems that part of the frustration is that people seem to agree that Folios does make things better, and yet they *still* are NACK'ing the patch series. The argument for why it should not be merged yet seems to be that it should be doing *more* --- that it doesn't go far enough. The opposing argument would be, "if folios improves things, and doesn't introduce any bugs, why shouldn't we merge it, reap the benefits, and then we can further evolve things?" As Linus said, "Linux is evolution, not intelligent design." - Ted