public inbox for linux-mm@kvack.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Matthew Wilcox <willy@infradead.org>
Cc: Christoph Hellwig <hch@lst.de>, Tal Zussman <tz2294@columbia.edu>,
	Jens Axboe <axboe@kernel.dk>,
	Christian Brauner <brauner@kernel.org>,
	"Darrick J. Wong" <djwong@kernel.org>,
	Carlos Maiolino <cem@kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>, Jan Kara <jack@suse.cz>,
	Dave Chinner <dgc@kernel.org>,
	Bart Van Assche <bvanassche@acm.org>,
	Gao Xiang <hsiangkao@linux.alibaba.com>,
	linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [PATCH 4/8] FOLD: block: change the defer in task context interface to be procedural
Date: Fri, 10 Apr 2026 08:17:25 +0200	[thread overview]
Message-ID: <20260410061725.GA24667@lst.de> (raw)
In-Reply-To: <adgJqiA0vivaW7NA@casper.infradead.org>

On Thu, Apr 09, 2026 at 09:18:50PM +0100, Matthew Wilcox wrote:
> On Thu, Apr 09, 2026 at 06:02:17PM +0200, Christoph Hellwig wrote:
> > @@ -1836,9 +1837,7 @@ void bio_endio(struct bio *bio)
> >  	}
> >  #endif
> >  
> > -	if (!in_task() && bio_flagged(bio, BIO_COMPLETE_IN_TASK))
> > -		bio_queue_completion(bio);
> > -	else if (bio->bi_end_io)
> > +	if (bio->bi_end_io)
> >  		bio->bi_end_io(bio);
> 
> What I liked about this before is that we had one central place that
> needed to be changed.  This change means that every bi_end_io now needs
> to check whether the BIO can be completed in its context.

Yes.  On the other hand we can actually use it when we don't know if
we need to offload beforehand, which enabls the two later conversions
and probably more.

> 
> > +++ b/fs/buffer.c
> > @@ -2673,6 +2673,9 @@ static void end_bio_bh_io_sync(struct bio *bio)
> >  {
> >  	struct buffer_head *bh = bio->bi_private;
> >  
> > +	if (buffer_dropbehind(bh) && bio_complete_in_task(bio))
> > +		return;
> 
> I really don't like this.  It assumes there's only one reason to
> complete in task context -- whether the buffer belongs to a dropbehind
> folio.  I want there to be other reasons.  Why would you introduce the
> new BH_dropbehind flag instead of checking BIO_COMPLETE_IN_TASK?

Because there's no BIO_COMPLETE_IN_TASK? left.

> >  	struct iomap_ioend *ioend = iomap_ioend_from_bio(bio);
> >  
> > +	/* Page cache invalidation cannot be done in irq context. */
> > +	if (ioend->io_flags & IOMAP_IOEND_DONTCACHE) {
> > +		if (bio_complete_in_task(bio))
> > +			return;
> > +	}
> 
> I thought we agreed to kill off IOMAP_IOEND_DONTCACHE?

Only IFF we don't need it.  With this version there is no way to just
remove it.


  reply	other threads:[~2026-04-10  6:17 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-09 16:02 bio completion in task enhancements / experiments Christoph Hellwig
2026-04-09 16:02 ` [PATCH 1/8] block: add BIO_COMPLETE_IN_TASK for task-context completion Christoph Hellwig
2026-04-09 16:02 ` [PATCH 2/8] iomap: use BIO_COMPLETE_IN_TASK for dropbehind writeback Christoph Hellwig
2026-04-09 16:02 ` [PATCH 3/8] block: enable RWF_DONTCACHE for block devices Christoph Hellwig
2026-04-09 16:02 ` [PATCH 4/8] FOLD: block: change the defer in task context interface to be procedural Christoph Hellwig
2026-04-09 20:18   ` Matthew Wilcox
2026-04-10  6:17     ` Christoph Hellwig [this message]
2026-04-09 16:02 ` [PATCH 5/8] FOLD: don't use in_task() to decide for offloading Christoph Hellwig
2026-04-09 16:02 ` [PATCH 6/8] iomap: use bio_complete_in_task for buffered read errors Christoph Hellwig
2026-04-09 16:02 ` [PATCH 7/8] iomap: use bio_complete_in_task for buffered write completions Christoph Hellwig
2026-04-09 16:02 ` [PATCH 8/8] RFC: use a TASK_FIFO kthread for read completion support Christoph Hellwig
2026-04-09 19:06   ` Tal Zussman
2026-04-10  6:19     ` 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=20260410061725.GA24667@lst.de \
    --to=hch@lst.de \
    --cc=axboe@kernel.dk \
    --cc=brauner@kernel.org \
    --cc=bvanassche@acm.org \
    --cc=cem@kernel.org \
    --cc=dgc@kernel.org \
    --cc=djwong@kernel.org \
    --cc=hsiangkao@linux.alibaba.com \
    --cc=jack@suse.cz \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=tz2294@columbia.edu \
    --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