On Tue, Sep 21, 2021 at 05:11:09PM -0400, Kent Overstreet wrote:

On Tue, Sep 21, 2021 at 09:38:54PM +0100, Matthew Wilcox wrote:

quoted

On Tue, Sep 21, 2021 at 03:47:29PM -0400, Johannes Weiner wrote:

quoted

and so the justification for replacing page with folio *below* those
entry points to address tailpage confusion becomes nil: there is no
confusion. Move the anon bits to anon_page and leave the shared bits
in page. That's 912 lines of swap_state.c we could mostly leave alone.

Your argument seems to be based on "minimising churn".  Which is certainly
a goal that one could have, but I think in this case is actually harmful.
There are hundreds, maybe thousands, of functions throughout the kernel
(certainly throughout filesystems) which assume that a struct page is
PAGE_SIZE bytes.  Yes, every single one of them is buggy to assume that,
but tracking them all down is a never-ending task as new ones will be
added as fast as they can be removed.

Yet it's only file backed pages that are actually changing in behaviour right
now - folios don't _have_ to be the tool to fix that elsewhere, for anon, for
network pools, for slab.

quoted

quoted

The anon_page->page relationship may look familiar too. It's a natural
type hierarchy between superclass and subclasses that is common in
object oriented languages: page has attributes and methods that are
generic and shared; anon_page and file_page encode where their
implementation differs.

A type system like that would set us up for a lot of clarification and
generalization of the MM code. For example it would immediately
highlight when "generic" code is trying to access type-specific stuff
that maybe it shouldn't, and thus help/force us refactor - something
that a shared, flat folio type would not.

If you want to try your hand at splitting out anon_folio from folio
later, be my guest.  I've just finished splitting out 'slab' from page,
and I'll post it later.  I don't think that splitting anon_folio from
folio is worth doing, but will not stand in your way.  I do think that
splitting tail pages from non-tail pages is worthwhile, and that's what
this patchset does.

Eesh, we can and should hold ourselves to a higher standard in our technical
discussions.

Let's not let past misfourtune (and yes, folios missing 5.15 _was_ unfortunate
and shouldn't have happened) colour our perceptions and keep us from having
productive working relationships going forward. The points Johannes is bringing
up are valid and pertinent and deserve to be discussed.

If you're still trying to sell folios as the be all, end all solution for
anything using compound pages, I think you should be willing to make the
argument that that really is the _right_ solution - not just that it was the one
easiest for you to implement.

Actual code might make this discussion more concrete and clearer. Could you post
your slab conversion?

Linus, I'd also like to humbly and publicly request that, despite it being past
the merge window and a breach of our normal process, folios still be merged for
5.15. Or failing that, that they're the first thing in for 5.16.

The reason for my request is that:

 - folios, at least in filesystem land, solve pressing problems and much work
   has been done on top of them assuming they go in, and the filesystem people
   seem to be pretty unanimous that we both want and need this

 - the public process and discussion has been a trainwreck. We're effectively
   arguing about the future of struct page, which is a "boiling the oceans" type
   issue, and the amount of mess that needs to be cleaned up makes it hard for
   parties working in different areas of the code with different interests and
   concerns to see the areas where we really do have common interests and goals

 - it's become apparent that there haven't been any real objections to the code
   that was queued up for 5.15. There _are_ very real discussions and points of
   contention still to be decided and resolved for the work beyond file backed
   pages, but those discussions were what derailed the more modest, and more
   badly needed, work that affects everyone in filesystem land

 - And, last but not least: it would really help with the frustration levels
   that have been making these discussions extroardinarily difficult. I think
   this whole thing has been showing that our process has some weak points where
   hopefully we'll do better in the future, but in the meantime - Matthew has
   been doing good and badly needed work, and he has my vote of confidence. I
   don't necessarily fully agree with _everything_ he wants to do with folios -
   I'm not writing a blank check here - but he's someone I can work with and
   want to continue to work with.

   Johannes too, for that matter.

Thanks and regards,
Kent