linux-kernel - Re: [MAINTAINER SUMMIT] Folios as a potential Kernel/Maintainers Summit topic?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YUNa5pWg4UT3ddai@moria.home.lan>
Date:   Thu, 16 Sep 2021 10:55:34 -0400
From:   Kent Overstreet <kent.overstreet@...il.com>
To:     Theodore Ts'o <tytso@....edu>
Cc:     James Bottomley <James.Bottomley@...senpartnership.com>,
        Chris Mason <clm@...com>, Johannes Weiner <hannes@...xchg.org>,
        Matthew Wilcox <willy@...radead.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "Darrick J. Wong" <djwong@...nel.org>,
        Christoph Hellwig <hch@...radead.org>,
        David Howells <dhowells@...hat.com>,
        "ksummit@...ts.linux.dev" <ksummit@...ts.linux.dev>
Subject: Re: [MAINTAINER SUMMIT] Folios as a potential Kernel/Maintainers
 Summit topic?

On Wed, Sep 15, 2021 at 04:48:55PM -0400, Theodore Ts'o wrote:
> On Wed, Sep 15, 2021 at 03:15:13PM -0400, James Bottomley wrote:
> > 
> > My reading of the email threads is that they're iterating to an actual
> > conclusion (I admit, I'm surprised) ... or at least the disagreements
> > are getting less.  Since the merge window closed this is now a 5.16
> > thing, so there's no huge urgency to getting it resolved next week.
> 
> My read was that it was more that people were just getting exhausted,
> and not necessarily that folks were converging.  (Also, Willy is
> currently on vacation.)
> 
> I'm happy to be wrong, bu the patches haven't changed since the merge
> window opened, and it's not clear what *needs* to change before it can
> be accepted at the next merge window.

I've personally been pretty dissapointed by how the discussions went off the
rails. I don't think Willy was doing the best job of explaining and advocating
for his design decisions, and some of the objections of the MM people have been
just crazypants.

One thing I want to make clear: folios aren't about compound pages, compound
pages are just the mechanism MM side for describing higher order allocations.
And folios are for filesystem pages (possibly including anonymous pages going
forward); they're _not_ for slab. 

Historically, we haven't had a clear allocator/allocatee interface or
distinction in our data structures, and our taxonomy of different types of pages
is also super confusing, and both of those things have been making these
discussions _really_ hard - but also, I expect better of some of you people. All
the bikeshedding over the naming and arguing over eventuallities that will never
happen because they're just pants on head stupid makes it really hard to find
people's _real_ legitimate objections when reading through these discussions. 

I'm probably waiting for Willy to get back from vacation so I can hear more of
his rationale before doing another long recap, and I'm still waiting for
Johannes to retract his NACK. One of the good things that's come out of the
discussions with Johannes is we've got some good concrete ideas for cutting
apart the struct page mess - Willy has done most of the initial work, after all
- and I think it's now possible to work towards a clear disctinction between
allocator and allocatee state and also separate data types for separate types of
pages. Fundamentally, the reason struct page exists at all is because we need
memory to be self describing, but a lot of stuff lives in struct page for more
for convenience reasons - we have a lot of code/data sharing there that's more
accidental than principled. But I'm starting to see a way forward and it's
getting me pretty excited.

> 
> > Well, the current one seems to be working (admittedly eventually, so
> > achieving faster resolution next time might be good) ... but I'm sure
> > you could propose alternatives ... especially in the time to resolution
> > department.
> 
> Given how long it took for DAX to converge (years and years and years
> and *multiple* LSF/MM's), I'm not as optimistic that Folios is
> converge and is about to be merged at the next merge window.  But
> again, I'm happy to be proven wrong.

I hope it doesn't take _that_ long...