lkml.org 
[lkml]   [2021]   [Sep]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Folios for 5.15 request - Was: re: Folio discussion recap -
    On Wed, Sep 22, 2021 at 11:46:04AM -0400, Kent Overstreet wrote:
    > 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.
    > >
    > > As Willy has repeatedly expressed a take-it-or-leave-it attitude in
    > > response to my feedback, I'm not excited about merging this now and
    > > potentially leaving quite a bit of cleanup work to others if the
    > > downstream discussion don't go to his liking.

    We're at a take-it-or-leave-it point for this pull request. The time
    for discussion was *MONTHS* ago.

    > > Here is the roughly annotated pull request:
    >
    > Thanks for breaking this out, Johannes.
    >
    > So: mm/filemap.c and mm/page-writeback.c - I disagree about folios not really
    > being needed there. Those files really belong more in fs/ than mm/, and the code
    > in those files needs folios the most - especially filemap.c, a lot of those
    > algorithms have to change from block based to extent based, making the analogy
    > with filesystems.
    >
    > I think it makes sense to drop the mm/lru stuff, as well as the mm/memcg,
    > mm/migrate and mm/workingset and mm/swap stuff that you object to - that is, the
    > code paths that are for both file + anonymous pages, unless Matthew has
    > technical reasons why that would break the rest of the patch set.

    Conceptually, it breaks the patch set. Anywhere that we convert back
    from a folio to a page, the guarantee of folios is weakened (and
    possibly violated). I don't think it makes sense from a practical point
    of view either; it's re-adding compound_head() calls that just don't
    need to be there.

    > That discussion can still happen... and there's still the potential to get a lot
    > more done if we're breaking open struct page and coming up with new types. I got
    > Matthew on board with what you wanted, re: using the slab allocator for larger
    > allocations

    Wait, no, you didn't. I think it's a terrible idea. It's just completely
    orthogonal to this patch set, so I don't want to talk about it.

    \
     
     \ /
      Last update: 2021-09-22 18:30    [W:2.064 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site