LKML Archive on
help / color / mirror / Atom feed
From: "Theodore Ts'o" <>
To: Kent Overstreet <>
Cc: James Bottomley <>,
	Chris Mason <>, Johannes Weiner <>,
	Matthew Wilcox <>,
	Linus Torvalds <>,
	"" <>,
	linux-fsdevel <>,
	"" <>,
	Andrew Morton <>,
	"Darrick J. Wong" <>,
	Christoph Hellwig <>,
	David Howells <>,
	"" <>
Subject: Re: [MAINTAINER SUMMIT] Folios as a potential Kernel/Maintainers Summit topic?
Date: Thu, 16 Sep 2021 21:42:21 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <YUOmG+qNxAxI9Kyn@moria.home.lan>

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."


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

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

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

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

  reply	other threads:[~2021-09-17  1:43 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-15 17:42 Theodore Ts'o
2021-09-15 18:03 ` James Bottomley
2021-09-15 18:20   ` Theodore Ts'o
2021-09-15 18:41     ` Chris Mason
2021-09-15 19:15       ` James Bottomley
2021-09-15 20:48         ` Theodore Ts'o
2021-09-16 14:55           ` Kent Overstreet
2021-09-16 13:51         ` David Howells
2021-09-16 16:46         ` Chris Mason
2021-09-16 17:11           ` James Bottomley
2021-09-16 19:15             ` Theodore Ts'o
2021-09-16 19:26               ` Andrew Morton
2021-09-16 20:16               ` Kent Overstreet
2021-09-17  1:42                 ` Theodore Ts'o [this message]
2021-09-17  4:58                   ` Kent Overstreet
2021-09-16 20:38             ` Chris Mason
2021-09-16 21:00               ` Konstantin Ryabitsev
2021-09-17 11:14                 ` James Bottomley
2021-09-17 12:36                   ` Konstantin Ryabitsev
2021-09-17 13:00                     ` James Bottomley
2021-09-17 14:36                       ` Chris Mason
2021-09-16 17:15           ` Kent Overstreet
2021-09-16 22:27             ` Chris Mason

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [MAINTAINER SUMMIT] Folios as a potential Kernel/Maintainers Summit topic?' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).