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
