* [PATCH] block: peek PM requests during runtime PM
@ 2022-06-10 9:06 赵武云
0 siblings, 0 replies; 3+ messages in thread
From: 赵武云 @ 2022-06-10 9:06 UTC (permalink / raw)
To: axboe; +Cc: linux-block, linux-kernel, zhaowuyun.zwy
[-- Attachment #1: Type: text/plain, Size: 151 bytes --]
Hi Jens,
please check this patch for 4.19 in the attachment.
because i can not use git send-email with email of our company, so i send attachment.
[-- Attachment #2: 0001-block-peek-PM-requests-during-runtime-PM.patch --]
[-- Type: application/octet-stream, Size: 3425 bytes --]
From c4733c7166b7e696ba5c6f4b78e10d40936aec04 Mon Sep 17 00:00:00 2001
From: Zhao Wuyun <zhaowuyun.zwy@alibaba-inc.com>
Date: Fri, 10 Jun 2022 16:01:43 +0800
Subject: [PATCH] block: peek PM requests during runtime PM
queue blocked during runtime PM when at the following situation:
process A:
runtime suspend run and set the PM status to RPM_SUSPENDING
then run req with RQF_PM with blk_execute_rq(req->q, NULL, req, 1)
then the req queued to head
it is not executed when the driver is busy
process B:
normal device management operation
run req with no RQF_PM with blk_execute_rq(req->q, NULL, req, 1)
the the req is queued in front of the RQF_PM req of process A
__blk_run_queue still not run
because the first req is non RQF_PM req and with RQF_SOFTBARRIER,
so the queue is totally blocked when at RPM_SUSPENDING status.
see the following task calltrace:
process A:
[<ffffff9d87e86150>] __switch_to+0x10c
[<ffffff9d88ed8ab0>] __schedule+0x670
[<ffffff9d88ed8d18>] schedule+0x74
[<ffffff9d88edc8f4>] schedule_timeout+0x328
[<ffffff9d88ed9130>] io_schedule_timeout+0x24
[<ffffff9d88ed9b10>] wait_for_common_io+0x90
[<ffffff9d88ed9bb4>] wait_for_completion_io_timeout+0x24
[<ffffff9d8829e1e0>] blk_execute_rq+0x88
[<ffffff9d8859b3a4>] scsi_execute+0x114
[<ffffff9d885c4070>] sd_sync_cache+0xfc
[<ffffff9d885c439c>] sd_suspend_common+0x58
[<ffffff9d885c4338>] sd_suspend_runtime+0x20
[<ffffff9d885a73cc>] scsi_runtime_suspend+0x70
[<ffffff9d885341e8>] __rpm_callback+0xcc
[<ffffff9d885340e8>] rpm_callback+0x5c
[<ffffff9d88532134>] rpm_suspend+0x1e8
[<ffffff9d88533b28>] pm_runtime_work+0x7c
[<ffffff9d87ed31d4>] process_one_work+0x1bc
[<ffffff9d87ed3668>] worker_thread+0x214
[<ffffff9d87ed839c>] kthread+0x11c
[<ffffff9d87e84fcc>] ret_from_fork+0x10
process B:
[<ffffff9d87e86150>] __switch_to+0x10c
[<ffffff9d88ed8ab0>] __schedule+0x670
[<ffffff9d88ed8d18>] schedule+0x74
[<ffffff9d88edc8f4>] schedule_timeout+0x328
[<ffffff9d88ed9130>] io_schedule_timeout+0x24
[<ffffff9d88ed9b10>] wait_for_common_io+0x90
[<ffffff9d88ed9bb4>] wait_for_completion_io_timeout+0x24
[<ffffff9d8829e1e0>] blk_execute_rq+0x88
[<ffffff9d8859b3a4>] scsi_execute+0x114
[<ffffff9d8859d854>] scsi_test_unit_ready+0x70
[<ffffff9d885c2f48>] sd_check_events+0xd4
[<ffffff9d882abde8>] disk_check_events+0x58
[<ffffff9d882acc0c>] disk_events_workfn+0x20
[<ffffff9d87ed31d4>] process_one_work+0x1bc
[<ffffff9d87ed3668>] worker_thread+0x214
[<ffffff9d87ed839c>] kthread+0x11c
[<ffffff9d87e84fcc>] ret_from_fork+0x10
Signed-off-by: Zhao Wuyun <zhaowuyun.zwy@alibaba-inc.com>
---
block/blk-core.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/block/blk-core.c b/block/blk-core.c
index a33775cd97be..8b9272bfdc09 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -2856,6 +2856,15 @@ static struct request *elv_next_request(struct request_queue *q)
if (blk_pm_allow_request(rq))
return rq;
+ /*
+ * let the PM request run,
+ * or the queue may be blocked by the non-PM request
+ * with RQF_SOFTBARRIER forever while doing runtime PM.
+ */
+ if (q->rpm_status == RPM_SUSPENDING
+ || q->rpm_status == RPM_RESUMING)
+ continue;
+
if (rq->rq_flags & RQF_SOFTBARRIER)
break;
}
--
2.32.1 (Apple Git-133)
^ permalink raw reply related [flat|nested] 3+ messages in thread
* [PATCH] block: peek PM requests during runtime PM
@ 2022-06-11 4:46 赵武云
2022-06-13 17:02 ` Christoph Hellwig
0 siblings, 1 reply; 3+ messages in thread
From: 赵武云 @ 2022-06-11 4:46 UTC (permalink / raw)
To: axboe, jejb, martin.petersen; +Cc: linux-block, linux-kernel
From: Zhao Wuyun <zhaowuyun.zwy@alibaba-inc.com>
queue blocked during runtime PM when at the following situation:
process A:
runtime suspend run and set the PM status to RPM_SUSPENDING
then run req with RQF_PM with blk_execute_rq(req->q, NULL, req, 1)
then the req queued to head
it is not executed when the driver is busy
process B:
normal device management operation
run req with no RQF_PM with blk_execute_rq(req->q, NULL, req, 1)
the the req is queued in front of the RQF_PM req of process A
__blk_run_queue still not run
because the first req is non RQF_PM req and with RQF_SOFTBARRIER,
so the queue is totally blocked when at RPM_SUSPENDING status.
see the following task calltrace:
process A:
[<ffffff9d87e86150>] __switch_to+0x10c
[<ffffff9d88ed8ab0>] __schedule+0x670
[<ffffff9d88ed8d18>] schedule+0x74
[<ffffff9d88edc8f4>] schedule_timeout+0x328
[<ffffff9d88ed9130>] io_schedule_timeout+0x24
[<ffffff9d88ed9b10>] wait_for_common_io+0x90
[<ffffff9d88ed9bb4>] wait_for_completion_io_timeout+0x24
[<ffffff9d8829e1e0>] blk_execute_rq+0x88
[<ffffff9d8859b3a4>] scsi_execute+0x114
[<ffffff9d885c4070>] sd_sync_cache+0xfc
[<ffffff9d885c439c>] sd_suspend_common+0x58
[<ffffff9d885c4338>] sd_suspend_runtime+0x20
[<ffffff9d885a73cc>] scsi_runtime_suspend+0x70
[<ffffff9d885341e8>] __rpm_callback+0xcc
[<ffffff9d885340e8>] rpm_callback+0x5c
[<ffffff9d88532134>] rpm_suspend+0x1e8
[<ffffff9d88533b28>] pm_runtime_work+0x7c
[<ffffff9d87ed31d4>] process_one_work+0x1bc
[<ffffff9d87ed3668>] worker_thread+0x214
[<ffffff9d87ed839c>] kthread+0x11c
[<ffffff9d87e84fcc>] ret_from_fork+0x10
process B:
[<ffffff9d87e86150>] __switch_to+0x10c
[<ffffff9d88ed8ab0>] __schedule+0x670
[<ffffff9d88ed8d18>] schedule+0x74
[<ffffff9d88edc8f4>] schedule_timeout+0x328
[<ffffff9d88ed9130>] io_schedule_timeout+0x24
[<ffffff9d88ed9b10>] wait_for_common_io+0x90
[<ffffff9d88ed9bb4>] wait_for_completion_io_timeout+0x24
[<ffffff9d8829e1e0>] blk_execute_rq+0x88
[<ffffff9d8859b3a4>] scsi_execute+0x114
[<ffffff9d8859d854>] scsi_test_unit_ready+0x70
[<ffffff9d885c2f48>] sd_check_events+0xd4
[<ffffff9d882abde8>] disk_check_events+0x58
[<ffffff9d882acc0c>] disk_events_workfn+0x20
[<ffffff9d87ed31d4>] process_one_work+0x1bc
[<ffffff9d87ed3668>] worker_thread+0x214
[<ffffff9d87ed839c>] kthread+0x11c
[<ffffff9d87e84fcc>] ret_from_fork+0x10
Signed-off-by: Zhao Wuyun <zhaowuyun.zwy@alibaba-inc.com>
---
block/blk-core.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/block/blk-core.c b/block/blk-core.c
index a33775cd97be..8b9272bfdc09 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -2856,6 +2856,15 @@ static struct request *elv_next_request(struct request_queue *q)
if (blk_pm_allow_request(rq))
return rq;
+ /*
+ * let the PM request run,
+ * or the queue may be blocked by the non-PM request
+ * with RQF_SOFTBARRIER forever while doing runtime PM.
+ */
+ if (q->rpm_status == RPM_SUSPENDING
+ || q->rpm_status == RPM_RESUMING)
+ continue;
+
if (rq->rq_flags & RQF_SOFTBARRIER)
break;
}
--
2.32.1 (Apple Git-133)
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] block: peek PM requests during runtime PM
2022-06-11 4:46 [PATCH] block: peek PM requests during runtime PM 赵武云
@ 2022-06-13 17:02 ` Christoph Hellwig
0 siblings, 0 replies; 3+ messages in thread
From: Christoph Hellwig @ 2022-06-13 17:02 UTC (permalink / raw)
To: 赵武云
Cc: axboe, jejb, martin.petersen, linux-block, linux-kernel
What tree is this against? Neither elv_next_request nor
blk_pm_allow_request exist in upstream, and haven't for a long time.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-06-13 19:08 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-06-11 4:46 [PATCH] block: peek PM requests during runtime PM 赵武云
2022-06-13 17:02 ` Christoph Hellwig
-- strict thread matches above, loose matches on Subject: below --
2022-06-10 9:06 赵武云
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).