public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: linux-fsdevel@vger.kernel.org
Cc: linux-xfs@vger.kernel.org, Wang Yugui <wangyugui@e16-tech.com>,
	Dave Chinner <david@fromorbit.com>,
	Christoph Hellwig <hch@infradead.org>,
	"Darrick J . Wong" <djwong@kernel.org>
Subject: Re: [PATCH v3 4/8] iomap: Remove unnecessary test from iomap_release_folio()
Date: Tue, 13 Jun 2023 17:19:20 +0100	[thread overview]
Message-ID: <ZIiXCPlmrDsOMVqp@casper.infradead.org> (raw)
In-Reply-To: <20230612203910.724378-5-willy@infradead.org>

On Mon, Jun 12, 2023 at 09:39:06PM +0100, Matthew Wilcox (Oracle) wrote:
> The check for the folio being under writeback is unnecessary; the caller
> has checked this and the folio is locked, so the folio cannot be under
> writeback at this point.
> 
> The comment is somewhat misleading in that it talks about one specific
> situation in which we can see a dirty folio.  There are others, so change
> the comment to explain why we can't release the iomap_page.

> +	 * If the folio is dirty, we refuse to release our metadata because
> +	 * it may be partially dirty (FIXME, add a test for that).

Argh, forgot to fix this.

        /*
         * If the folio is dirty, we refuse to release our metadata because
-        * it may be partially dirty (FIXME, add a test for that).
+        * it may be partially dirty.  Once we track per-block dirty state,
+        * we can release the metadata if every block is dirty.
         */

> -	if (folio_test_dirty(folio) || folio_test_writeback(folio))
> +	if (folio_test_dirty(folio))
>  		return false;

Now I'm wondering if we shouldn't also refuse to release the metadata if
the folio is !uptodate.  It's not a correctness issue, it's a performance
issue, and a question of whose priorities are more important.

If we do release the metadata on a partially uptodate folio, we'll
re-read the parts of the folio from storage which had previously been
successfully read.  If we don't release the metadata, we prevent the
MM from splitting the page (eg on truncate).

No obviously right answer here, IMO.


  parent reply	other threads:[~2023-06-13 16:19 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-12 20:39 [PATCH v3 0/8] Create large folios in iomap buffered write path Matthew Wilcox (Oracle)
2023-06-12 20:39 ` [PATCH v3 1/8] iov_iter: Handle compound highmem pages in copy_page_from_iter_atomic() Matthew Wilcox (Oracle)
2023-06-13  4:52   ` Christoph Hellwig
2023-07-10  3:36     ` Matthew Wilcox
2023-06-12 20:39 ` [PATCH v3 2/8] iomap: Remove large folio handling in iomap_invalidate_folio() Matthew Wilcox (Oracle)
2023-06-12 20:39 ` [PATCH v3 3/8] doc: Correct the description of ->release_folio Matthew Wilcox (Oracle)
2023-06-13  4:53   ` Christoph Hellwig
2023-06-12 20:39 ` [PATCH v3 4/8] iomap: Remove unnecessary test from iomap_release_folio() Matthew Wilcox (Oracle)
2023-06-13  4:53   ` Christoph Hellwig
2023-06-13 16:19   ` Matthew Wilcox [this message]
2023-06-12 20:39 ` [PATCH v3 5/8] filemap: Add fgf_t typedef Matthew Wilcox (Oracle)
2023-06-13  4:53   ` Christoph Hellwig
2023-06-12 20:39 ` [PATCH v3 6/8] filemap: Allow __filemap_get_folio to allocate large folios Matthew Wilcox (Oracle)
2023-06-12 22:49   ` Dave Chinner
2023-06-13  0:42     ` Matthew Wilcox
2023-06-13  1:30       ` Dave Chinner
2023-06-13  2:00         ` Matthew Wilcox
2023-06-13  7:54           ` Dave Chinner
2023-06-13 13:34             ` Matthew Wilcox
2023-06-16 17:45             ` Matthew Wilcox
2023-06-16 22:40               ` Dave Chinner
2023-06-13  4:56   ` Christoph Hellwig
2023-06-12 20:39 ` [PATCH v3 7/8] iomap: Create large folios in the buffered write path Matthew Wilcox (Oracle)
2023-06-13  4:56   ` Christoph Hellwig
2023-06-12 20:39 ` [PATCH v3 8/8] iomap: Copy larger chunks from userspace Matthew Wilcox (Oracle)
2023-06-13  4:58   ` Christoph Hellwig
2023-06-13 19:43     ` Matthew Wilcox
2023-07-10  3:45       ` Matthew Wilcox
2023-06-17  7:13   ` Ritesh Harjani
2023-06-19 17:09     ` Matthew Wilcox
2023-07-10  3:57       ` Matthew Wilcox
2023-06-21 12:03 ` [PATCH v3 0/8] Create large folios in iomap buffered write path Wang Yugui
2023-07-10  3:55   ` Matthew Wilcox

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=ZIiXCPlmrDsOMVqp@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=david@fromorbit.com \
    --cc=djwong@kernel.org \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=wangyugui@e16-tech.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