linux-kernel - Re: Folios for 5.15 request - Was: re: Folio discussion recap -

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: <YUwTuaZlzx2WLXcG@moria.home.lan>
Date:   Thu, 23 Sep 2021 01:42:17 -0400
From:   Kent Overstreet <kent.overstreet@...il.com>
To:     Johannes Weiner <hannes@...xchg.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Matthew Wilcox <willy@...radead.org>, linux-mm@...ck.org,
        linux-fsdevel@...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>
Subject: Re: Folios for 5.15 request - Was: re: Folio discussion recap -

On Wed, Sep 22, 2021 at 11:08:58AM -0400, Johannes Weiner wrote:
> On Tue, Sep 21, 2021 at 05:22:54PM -0400, Kent Overstreet wrote:
> >  - 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
> 
> Unfortunately, I think this is a result of me wanting to discuss a way
> forward rather than a way back.
> 
> To clarify: I do very much object to the code as currently queued up,
> and not just to a vague future direction.
> 
> The patches add and convert a lot of complicated code to provision for
> a future we do not agree on. The indirections it adds, and the hybrid
> state it leaves the tree in, make it directly more difficult to work
> with and understand the MM code base. Stuff that isn't needed for
> exposing folios to the filesystems.

I think something we need is an alternate view - anon_folio, perhaps - and an
idea of what that would look like. Because you've been saying you don't think
file pages and anymous pages are similar enough to be the same time - so if
they're not, how's the code that works on both types of pages going to change to
accomadate that?

Do we have if (file_folio) else if (anon_folio) both doing the same thing, but
operating on different types? Some sort of subclassing going on?

I was agreeing with you that slab/network pools etc. shouldn't be folios - that
folios shouldn't be a replacement for compound pages. But I think we're going to
need a serious alternative proposal for anonymous pages if you're still against
them becoming folios, especially because according to Kirill they're already
working on that (and you have to admit transhuge pages did introduce a mess that
they will help with...)