在 2025/8/27 19:15, Jan Kara 写道:
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.
Ah, thanks for the clarification. It may be a little bit difficult to
reproduce it manually, I’ll give it a shot but I’m not sure if I can do
it..>
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.
Thanks, I will send a patch to improve here.>
Honza
--
Julian Sun <sunjunchao@xxxxxxxxxxxxx>
