Hi Julian, On Thu, Jul 31, 2025 at 8:33 PM Julian Sun <sunjunchao2870@xxxxxxxxx> wrote: > > Recently, we encountered the following hungtask: > > INFO: task kworker/11:2:2981147 blocked for more than 6266 seconds > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > kworker/11:2 D 0 2981147 2 0x80004000 > Workqueue: cgroup_destroy css_free_rwork_fn > Call Trace: > __schedule+0x934/0xe10 > schedule+0x40/0xb0 > wb_wait_for_completion+0x52/0x80 I don’t see __wbt_wait() or rq_qos_wait() here, so I suspect this call stack is not directly related to wbt. > ? finish_wait+0x80/0x80 > mem_cgroup_css_free+0x3a/0x1b0 > css_free_rwork_fn+0x42/0x380 > process_one_work+0x1a2/0x360 > worker_thread+0x30/0x390 > ? create_worker+0x1a0/0x1a0 > kthread+0x110/0x130 > ? __kthread_cancel_work+0x40/0x40 > ret_from_fork+0x1f/0x30 > > This is because the writeback thread has been continuously and repeatedly > throttled by wbt, but at the same time, the writes of another thread > proceed quite smoothly. > After debugging, I believe it is caused by the following reasons. > > When thread A is blocked by wbt, the I/O issued by thread B will > use a deeper queue depth(rwb->rq_depth.max_depth) because it > meets the conditions of wb_recent_wait(), thus allowing thread B's > I/O to be issued smoothly and resulting in the inflight I/O of wbt > remaining relatively high. > > However, when I/O completes, due to the high inflight I/O of wbt, > the condition "limit - inflight >= rwb->wb_background / 2" > in wbt_rqw_done() cannot be satisfied, causing thread A's I/O > to remain unable to be woken up.
