Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Matthew Wilcox <willy@infradead.org>
Cc: Pedro Falcato <pfalcato@suse.de>, Christoph Hellwig <hch@lst.de>,
	Jann Horn <jannh@google.com>, David Howells <dhowells@redhat.com>,
	John Hubbard <jhubbard@nvidia.com>, Jan Kara <jack@suse.cz>,
	Rik van Riel <riel@surriel.com>, Qu Wenruo <wqu@suse.com>,
	"Darrick J. Wong" <djwong@kernel.org>,
	linux-btrfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org, linux-xfs@vger.kernel.org
Subject: Re: Removing ->dirty_folio
Date: Tue, 25 Aug 2026 09:39:18 +0200	[thread overview]
Message-ID: <20260825073918.GA25441@lst.de> (raw)
In-Reply-To: <aoyWln-Gt-yvZQkE@casper.infradead.org>

On Mon, Aug 24, 2026 at 08:08:06PM +0100, Matthew Wilcox wrote:
> My proposal is this:
> 
>  - Fileystems take note of folio_maybe_dma_pinned() during writeback.
>    If it's true, do the writeback, but retain/recreate whatever data
>    structures you need in order to write the folio again; behave as if
>    ->page_mkdirty() had been called again for each page in the folio is
>    marked as dirty.
>  - The MM behaves similarly; we do not clear the writeback flag for
>    folio_maybe_dma_pinned().
> 
> This will have the effect of writing pinned folios back every time the
> inode is scheduled for writeback.  But since we have no idea whether
> the folio is actually dirty (because the GUP user won't tell us),
> this is the correct behaviour.
> 
> I'm probably missing some stuff here.  Let me know.

We've been through this a few times, I remember me and Jan discussing
it maybe a year or so on the list last.  This is what I remember:

 - the best thing would be to just not write folio_maybe_dma_pinned
   folios at all.  Jan brought up cases where that might not be
   possible, so we might have to write anyway.  IIRC the major
   one is that we actually do allow FOLL_LONGTERM even on file
   backed mappings, and those could be pinned forever.
 - when we write them anyway we really have to bounce buffer the
   data.  Basically copy and do something like in-kernel direct I/O
 - Even that can be tricky, because we'd still need a space reservation
   for that write at it would otherwise consume the space reservation
   at dirty time, but we still might have to write it again.  One
   option might be to only do the force bounce buffer write for
   FOLL_LONGTERM as the others should go away, and FOLL_LONGTERM
   gets a call into the fs to reserve extra space.  This would not
   be enough for a lot of writes, but enough to allow for
   "bank switching" over GC cycles.

So, not perfect, but probably better than the status quo.  But a lot
of work that someone needs to do for being a bit better than the
status quo.

  parent reply	other threads:[~2026-08-25  7:39 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-24 19:08 Removing ->dirty_folio Matthew Wilcox
2026-08-24 19:25 ` John Hubbard
2026-08-24 19:43   ` Matthew Wilcox
2026-08-24 19:51     ` John Hubbard
2026-08-24 21:05       ` Matthew Wilcox
2026-08-25  7:59     ` Pedro Falcato
2026-08-24 19:33 ` Rik van Riel
2026-08-25  8:21   ` David Hildenbrand (Arm)
2026-08-24 21:27 ` Boris Burkov
2026-08-25 19:47   ` Matthew Wilcox
2026-08-24 22:38 ` Qu Wenruo
2026-08-25 19:26   ` Matthew Wilcox
2026-08-25 22:33     ` Qu Wenruo
2026-08-26  4:53       ` Christoph Hellwig
2026-08-26  8:01     ` Christoph Hellwig
2026-08-25  6:48 ` David Howells
2026-08-25 19:16   ` Matthew Wilcox
2026-08-25  7:39 ` Christoph Hellwig [this message]
2026-08-25 19:14   ` Matthew Wilcox
2026-08-25  8:25 ` Pedro Falcato
2026-08-25 18:35   ` Matthew Wilcox
2026-08-25 19:35 ` Jann Horn
2026-08-25 19:54   ` Matthew Wilcox
2026-08-25 20:06     ` Jann Horn
2026-08-26  0:02       ` Matthew Wilcox
2026-08-26  5:07     ` Christoph Hellwig
2026-08-26  7:42       ` Christoph Hellwig

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20260825073918.GA25441@lst.de \
    --to=hch@lst.de \
    --cc=dhowells@redhat.com \
    --cc=djwong@kernel.org \
    --cc=jack@suse.cz \
    --cc=jannh@google.com \
    --cc=jhubbard@nvidia.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=pfalcato@suse.de \
    --cc=riel@surriel.com \
    --cc=willy@infradead.org \
    --cc=wqu@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox