mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Zhang Yi <yi.zhang@huaweicloud.com>
To: Tal Zussman <tz2294@columbia.edu>
Cc: Theodore Ts'o <tytso@mit.edu>, Jan Kara <jack@suse.cz>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Baokun Li <libaokun@linux.alibaba.com>,
	Ojaswin Mujoo <ojaswin@linux.ibm.com>,
	"Ritesh Harjani (IBM)" <ritesh.list@gmail.com>,
	Taotao Chen <chentaotao@didiglobal.com>,
	Christian Brauner <brauner@kernel.org>,
	Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>,
	"Matthew Wilcox (Oracle)" <willy@infradead.org>,
	linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ext4: complete dropbehind writeback in task context
Date: Wed, 14 Oct 2026 11:36:58 +0800	[thread overview]
Message-ID: <4e9df882-6379-4118-9dbf-c8f3fcb75058@huaweicloud.com> (raw)
In-Reply-To: <ef6d0df9-c71a-4b42-bde2-efc4477306ed@columbia.edu>

On 10/14/2026 1:32 AM, Tal Zussman wrote:
> On 10/13/26 8:47 AM, Jan Kara wrote:
>> On Mon 12-10-26 14:04:37, Tal Zussman wrote:
>>> ext4_end_bio() ends writeback directly from bio completion, which
>>> usually runs in interrupt context, unless the io_end has unwritten
>>> extents to convert and is completed from ext4's workqueue.
>>> folio_end_dropbehind() only invalidates the folios of an RWF_DONTCACHE
>>> write when it runs in task context, and silently skips them otherwise.
>>> So on ext4, dontcache writes that overwrite blocks that are already
>>> written, or that allocate blocks without unwritten extents, leave their
>>> folios in the page cache. Dropping them was best effort so far, as there
>>> was no way to get task context from bio completion.
>>>
>>> Use the task-context bio completion infrastructure instead: set
>>> BIO_COMPLETE_IN_TASK on bios that carry dropbehind folios in
>>> io_submit_add_bh(), so that bio_endio() runs their completion from a
>>> worker. ext4's iomap buffered I/O path already gets this from iomap, so
>>> only the buffer_head based writeback is affected. Skip the flag when the
>>> io_end already has unwritten extents, as ext4 then defers the completion
>>> itself. A later extent can still make the io_end unwritten after an
>>> earlier bio was built. That bio's completion is then deferred twice,
>>> which is not optimal, but harmless.
>>>
>>> This changes behavior only for bios that carry dropbehind folios: their
>>> completion now runs from a worker instead of in interrupt context.
>>>
>>> On the unpatched kernel a dontcache overwrite of already-written blocks,
>>> or a dontcache write into a new file on a dioread_lock mount, leaves
>>> every folio in the page cache (16384/16384 for a 64M file). With the
>>> patch, none remain in the page cache. A dontcache write into a new file
>>> with unwritten extents already drops its folios on both kernels, as
>>> expected, and a plain write keeps them.
>>>
>>> Signed-off-by: Tal Zussman <tz2294@columbia.edu>
>>
>> I guess this is OK as a short term fix but having two different offloading
>> mechanisms for IO completion is just asking for trouble and we should use
>> BIO_COMPLETE_IN_TASK when unwritten extent conversion is needed as well.
>> But for this fix feel free to add:
>>
>> Reviewed-by: Jan Kara <jack@suse.cz>
>>
> 

Ha, I also noticed this issue in the buffer_head path when I was adding
the iomap path earlier. I was planned to start addressing the generic
bio completion converting work across both writeback paths after the
current stage of work wraps up, so thanks for fixing this one separately!

Reviewed-by: Zhang Yi <yi.zhang@huawei.com>


> Thanks! Agreed on the above. I saw that there was a TODO added in
> ext4_iomap_writeback_submit() from the new iomap conversion series to
> "switch all defer handlers to the generic bio complete in task framework",
> so I assumed that'll be taken care of as part of the ongoing conversion.
> 

Yes, Jan discussed this optimization direction with me previously. Next,
I'll try to remove ext4's own deferred workqueue and migrate the work
into the generic flow.

Thanks,
Yi.

> - Tal
> 
>> 								Honza
>>
>>> ---
>>>  fs/ext4/page-io.c | 10 ++++++++++
>>>  1 file changed, 10 insertions(+)
>>>
>>> diff --git a/fs/ext4/page-io.c b/fs/ext4/page-io.c
>>> index 734d856a6d47..e556598ce9e1 100644
>>> --- a/fs/ext4/page-io.c
>>> +++ b/fs/ext4/page-io.c
>>> @@ -458,6 +458,16 @@ static void io_submit_add_bh(struct ext4_io_submit *io,
>>>  		io_submit_init_bio(io, inode, folio, bh);
>>>  	if (!bio_add_folio(io->io_bio, folio, bh->b_size, bh_offset(bh)))
>>>  		goto submit_and_retry;
>>> +
>>> +	/*
>>> +	 * Dropbehind folios can only be invalidated in task context. An
>>> +	 * io_end with unwritten extents is completed from ext4's workqueue
>>> +	 * anyway, so only ask the block layer to defer the others.
>>> +	 */
>>> +	if (folio_test_dropbehind(folio) &&
>>> +	    !(io->io_end->flag & EXT4_IO_END_UNWRITTEN))
>>> +		bio_set_flag(io->io_bio, BIO_COMPLETE_IN_TASK);
>>> +
>>>  	wbc_account_cgroup_owner(io->io_wbc, folio, bh->b_size);
>>>  	io->io_next_block++;
>>>  }
>>>
>>> ---
>>> base-commit: 35aefefd7aba0801bab635b11943f932626be3b2
>>> change-id: 20260924-ext4-dontcache-complete-in-task-2340ed5f3114
>>>
>>> Best regards,
>>> --  
>>> Tal Zussman <tz2294@columbia.edu>
>>>
>> -- 
>> Jan Kara <jack@suse.com>
>> SUSE Labs, CR
>>
> 
> 


  reply	other threads:[~2026-10-14  3:37 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-12 18:04 Tal Zussman
2026-10-13 11:59 ` Christoph Hellwig
2026-10-13 17:36   ` Tal Zussman
2026-10-13 12:47 ` Jan Kara
2026-10-13 17:32   ` Tal Zussman
2026-10-14  3:36     ` Zhang Yi [this message]
2026-10-13 15:17 ` Baokun Li

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=4e9df882-6379-4118-9dbf-c8f3fcb75058@huaweicloud.com \
    --to=yi.zhang@huaweicloud.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=axboe@kernel.dk \
    --cc=brauner@kernel.org \
    --cc=chentaotao@didiglobal.com \
    --cc=hch@lst.de \
    --cc=jack@suse.cz \
    --cc=libaokun@linux.alibaba.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ojaswin@linux.ibm.com \
    --cc=ritesh.list@gmail.com \
    --cc=tytso@mit.edu \
    --cc=tz2294@columbia.edu \
    --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

all inboxes | Powered by JetHome®