linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Christoph Hellwig <hch@infradead.org>
Cc: Jeff Layton <jlayton@kernel.org>,
	 Alexander Viro <viro@zeniv.linux.org.uk>,
	Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
	 "Matthew Wilcox (Oracle)" <willy@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	 David Hildenbrand <david@kernel.org>,
	Lorenzo Stoakes <ljs@kernel.org>,
	 "Liam R. Howlett" <Liam.Howlett@oracle.com>,
	Vlastimil Babka <vbabka@kernel.org>,
	 Mike Rapoport <rppt@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	 Michal Hocko <mhocko@suse.com>,
	Mike Snitzer <snitzer@kernel.org>, Jens Axboe <axboe@kernel.dk>,
	 Chuck Lever <chuck.lever@oracle.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	 linux-nfs@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH v2 1/3] mm: kick writeback flusher instead of inline flush for IOCB_DONTCACHE
Date: Thu, 9 Apr 2026 09:21:36 +0200	[thread overview]
Message-ID: <gpcc6t5unsoepakjdffsmnmd5duuvijxwdochd753ttix75h7l@nahwzi4qfdcq> (raw)
In-Reply-To: <adc-Q1iDWHD5yxHH@infradead.org>

On Wed 08-04-26 22:50:59, Christoph Hellwig wrote:
> On Wed, Apr 08, 2026 at 10:25:21AM -0400, Jeff Layton wrote:
> > +/**
> > + * filemap_dontcache_kick_writeback - kick flusher for IOCB_DONTCACHE writes
> > + * @mapping:	address_space that was just written to
> > + *
> > + * Wake the BDI flusher thread to start writeback of dirty pages in the
> > + * background.
> > + */
> > +void filemap_dontcache_kick_writeback(struct address_space *mapping)
> > +{
> > +	wakeup_flusher_threads_bdi(inode_to_bdi(mapping->host),
> > +				   WB_REASON_DONTCACHE);
> > +}
> 
> wakeup_flusher_threads_bdi ends up calling wb_start_writeback eventually,
> which sets WB_start_all, pushes the reason to start_all_reason and then
> does the actual wakeup.
> 
> The flusher thread then through wb_check_start_all does a WB_SYNC_NONE
> writeback based on get_nr_dirty_pages.  Which seems wrong - we don't
> want to do a huge writeback evertime the some DONTCACHE write finished.

This is all true and I can certainly construct a workload where this
behavior will lead to big regressions in performance - for example one
process creating say 1G temporary file and deleting it shortly after
creation + one process doing small DONTCACHE writes. Before this change
only DONTCACHE writes will make it to the disk and temporary file will only
be in the page cache, after this change you pay for allocating, writing
back, and deleting the temporary file.

> So I think you'll want a new WB_start_dontcache bit, a new
> get_nr_dontcache_pages() helper on a new node counter, etc.

But I'm not sure how you imagine this would work without restricting
writeback to particular inodes. Maybe we could mark inodes which have
folios with dropbehind set and make flush worker only write such inodes?
That would probably require tracking number of folios with dropbehind flag
per inode but that wouldn't be too bad. Or we could just lazily clear this
"inode has dropbehind folios" flag once the inode is clean.

								Honza

-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR


  reply	other threads:[~2026-04-09  7:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-08 14:25 [PATCH v2 0/3] mm: improve write performance with RWF_DONTCACHE Jeff Layton
2026-04-08 14:25 ` [PATCH v2 1/3] mm: kick writeback flusher instead of inline flush for IOCB_DONTCACHE Jeff Layton
2026-04-09  1:40   ` Ritesh Harjani
2026-04-09  5:52     ` Christoph Hellwig
2026-04-09  5:50   ` Christoph Hellwig
2026-04-09  7:21     ` Jan Kara [this message]
2026-04-08 14:25 ` [PATCH v2 2/3] testing: add nfsd-io-bench NFS server benchmark suite Jeff Layton
2026-04-08 14:25 ` [PATCH v2 3/3] testing: add dontcache-bench local filesystem " Jeff Layton
2026-04-08 18:45 ` [PATCH v2 0/3] mm: improve write performance with RWF_DONTCACHE Jeff Layton
2026-04-09  6:06   ` Christoph Hellwig
2026-04-09  6:05 ` 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=gpcc6t5unsoepakjdffsmnmd5duuvijxwdochd753ttix75h7l@nahwzi4qfdcq \
    --to=jack@suse.cz \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=brauner@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=david@kernel.org \
    --cc=hch@infradead.org \
    --cc=jlayton@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=ljs@kernel.org \
    --cc=mhocko@suse.com \
    --cc=rppt@kernel.org \
    --cc=snitzer@kernel.org \
    --cc=surenb@google.com \
    --cc=vbabka@kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.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