public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Chris Mason <clm@meta.com>
Cc: Christoph Hellwig <hch@infradead.org>, Chris Mason <clm@fb.com>,
	linux-btrfs@vger.kernel.org, Josef Bacik <josef@toxicpanda.com>,
	David Sterba <dsterba@suse.com>,
	linux-mm@kvack.org
Subject: Re: What is the point of the wbc->for_kupdate check in btree_writepages
Date: Thu, 8 May 2025 07:41:50 -0700	[thread overview]
Message-ID: <aBzCrkI7Jfisdnaw@infradead.org> (raw)
In-Reply-To: <2d1a8e78-b57a-4726-a566-4d916a36be8f@meta.com>

On Thu, May 08, 2025 at 10:33:24AM -0400, Chris Mason wrote:
> btrfs can keep changing dirty tree blocks in memory, but once we write
> them, we have to recow.  Between transaction writeback kicking in every
> 30 seconds and us calling balance_dirty_pages on the btree inode,
> kupdate was doing more harm than good (back in 2007).

I totally understand why you'd want to avoid background writeback.  I
just don't understand why it singles out for_kupdate.

> Is the goal to get rid of for_kupdate?

At least getting rid of exposing it to file systems, yes.

> I wonder if we can just flag the
> btree inode to exclude from kupdate, or keep it off whatever list
> kupdate cares about etc.

Not having the VM do writeback on metadata but running it from a fs
LRU was a huge win in XFS.  I'm not sure we have interfaces that keep
data in the pagecache but never do any background writeback.  But
if you are fine with treating all background writeback equal that
would be exactly where I'd like to go to.


  reply	other threads:[~2025-05-08 14:41 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-08  6:06 What is the point of the wbc->for_kupdate check in btree_writepages Christoph Hellwig
2025-05-08 14:33 ` Chris Mason
2025-05-08 14:41   ` Christoph Hellwig [this message]
2025-05-08 16:11     ` Chris Mason

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=aBzCrkI7Jfisdnaw@infradead.org \
    --to=hch@infradead.org \
    --cc=clm@fb.com \
    --cc=clm@meta.com \
    --cc=dsterba@suse.com \
    --cc=josef@toxicpanda.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /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