On Wed 27-08-25 12:57:32, Julian Sun wrote:
> 在 2025/8/27 04:55, Ritesh Harjani (IBM) 写道:
> > Julian Sun <sunjunchao@xxxxxxxxxxxxx> writes:
> >
> > > In commit 6a3afb6ac6df ("jbd2: increase the journal IO's priority"),
> > > the priority of IOs initiated by jbd2 has been raised, exempting them
> > > from WBT throttling.
> > > Checkpoint is also a crucial operation of jbd2. While no serious issues
> > > have been observed so far, it should still be reasonable to exempt
> > > checkpoint from WBT throttling.
> > >
> >
> > Interesting.. I was wondering whether we were able to observe any
> > throttling for jbd2 log writes or for jbd2 checkpoint?
> > Maybe It would have been nice, if we had some kind of data for this.
>
> Good idea. But AFAICS wbt lacks of such a obversation mechanism now..>
Well, I guess Ritesh meant some test case which is reproducing the
situation where jbd2 log writes get stalled.
> > BTW - does it make sense for fastcommit path too maybe for non-tail
> > fc write requests? I think it uses ext4_fc_submit_bh().
>
> Yeah, I think so.
> After a rough check of the code, the following code paths may result in high
> latency or even task hangs:
> 1. fastcommit io is throttled by wbt or other block layer qos policies.
> 2. jbd2_fc_wait_bufs() might wait for a long time while
> JBD2_FAST_COMMIT_ONGOING is set in journal->flags, and then
> jbd2_journal_commit_transaction() waits for the JBD2_FAST_COMMIT_ONGOING bit
> for a long time while holding the write lock of j_state_lock.
> 3. start_this_handle() waits for read lock of j_state_lock which results
> in high latency or task hang.
>
> Hi, Jan, please correct me if I'm missing anything.
I think you're correct. In fact ext4_fc_commit() does modify current
process' io priority to match that of jbd2 thread so it would be logical
to match IO submission flags as well.
Honza
--
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR
