From: Zqiang <[email protected]>
In 'io_wqe_worker' thread, if the work which in 'wqe->work_list' be
finished, the 'wqe->work_list' is empty, and after that the
'__io_worker_idle' func return false, the task state is TASK_RUNNING,
need to be set TASK_INTERRUPTIBLE before call schedule_timeout func.
Signed-off-by: Zqiang <[email protected]>
---
fs/io-wq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/io-wq.c b/fs/io-wq.c
index 02894df7656d..5f0626935b64 100644
--- a/fs/io-wq.c
+++ b/fs/io-wq.c
@@ -618,7 +618,7 @@ static int io_wqe_worker(void *data)
raw_spin_unlock_irq(&wqe->lock);
if (signal_pending(current))
flush_signals(current);
- if (schedule_timeout(WORKER_IDLE_TIMEOUT))
+ if (schedule_timeout_interruptible(WORKER_IDLE_TIMEOUT))
continue;
/* timed out, exit unless we're the fixed worker */
if (test_bit(IO_WQ_BIT_EXIT, &wq->state) ||
--
2.17.1
On 10/26/20 9:09 PM, [email protected] wrote:
> From: Zqiang <[email protected]>
>
> In 'io_wqe_worker' thread, if the work which in 'wqe->work_list' be
> finished, the 'wqe->work_list' is empty, and after that the
> '__io_worker_idle' func return false, the task state is TASK_RUNNING,
> need to be set TASK_INTERRUPTIBLE before call schedule_timeout func.
I don't think that's safe - what if someone added work right before you
call schedule_timeout_interruptible? Something ala:
io_wq_enqueue()
set_current_state(TASK_INTERRUPTIBLE();
schedule_timeout(WORKER_IDLE_TIMEOUT);
then we'll have work added and the task state set to running, but the
worker itself just sets us to non-running and will hence wait
WORKER_IDLE_TIMEOUT before the work is processed.
The current situation will do one extra loop for this case, as the
schedule_timeout() just ends up being a nop and we go around again
checking for work. Since we already unused the mm, the next iteration
will go to sleep properly unless new work came in.
--
Jens Axboe
________________________________________
??????: Jens Axboe <[email protected]>
????ʱ??: 2020??10??27?? 21:35
?ռ???: Zhang, Qiang
????: [email protected]; [email protected]
????: Re: [PATCH] io-wq: set task TASK_INTERRUPTIBLE state before schedule_timeout
On 10/26/20 9:09 PM, [email protected] wrote:
> From: Zqiang <[email protected]>
>
> In 'io_wqe_worker' thread, if the work which in 'wqe->work_list' be
> finished, the 'wqe->work_list' is empty, and after that the
> '__io_worker_idle' func return false, the task state is TASK_RUNNING,
> need to be set TASK_INTERRUPTIBLE before call schedule_timeout func.
>
>I don't think that's safe - what if someone added work right before you
>call schedule_timeout_interruptible? Something ala:
>
>
>io_wq_enqueue()
> set_current_state(TASK_INTERRUPTIBLE();
> schedule_timeout(WORKER_IDLE_TIMEOUT);
>
>then we'll have work added and the task state set to running, but the
>worker itself just sets us to non-running and will hence wait
>WORKER_IDLE_TIMEOUT before the work is processed.
>
>The current situation will do one extra loop for this case, as the
>schedule_timeout() just ends up being a nop and we go around again
although the worker task state is running, due to the call schedule_timeout, the
current worker still possible to be switched out.
if set current worker task is no-running, the current worker be switched out, but
the schedule will call io_wq_worker_sleeping func to wake up free worker task, if
wqe->free_list is not empty.
>checking for work. Since we already unused the mm, the next iteration
>will go to sleep properly unless new work came in.
>
>--
>Jens Axboe