On 12/3/2022 2:16 AM, Bjorn Andersson wrote:
On Fri, Dec 02, 2022 at 05:45:32PM +0800, Maria Yu wrote:
Only the first detected crash needed to be handled, so change
to ordered workqueue to avoid unnecessary multi active work at
the same time.
In cab8300b5621 ("remoteproc: Use unbounded workqueue for recovery
work") Mukesh specifically said that it was required that multiple
remoteproc instances should be allowed to recover concurrently.
Is this no longer the case? Or am I perhaps misunderstanding the
nuances of the different work queue models?
This will reduce the pm_relax unnecessary concurrency.
I'm not sure I understand this sentence, unless I remove the word
"pm_relax", was it added by mistake?
If so, is the support for concurrent recovery really unnecessary?
I know we have cases where we spend time in the recovery process just
waiting for things to happen, so allowing recovery to run concurrent
between instances sounds like a good idea.
Agree with you.
Allowing recovery to run concurrent for different subsystem still seems
a good idea currently. Let's drop this change.
Regards,
Bjorn
Signed-off-by: Maria Yu <quic_aiquny@xxxxxxxxxxx>
---
drivers/remoteproc/remoteproc_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
index c2d0af048c69..4b973eea10bb 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -2728,8 +2728,8 @@ static void __exit rproc_exit_panic(void)
static int __init remoteproc_init(void)
{
- rproc_recovery_wq = alloc_workqueue("rproc_recovery_wq",
- WQ_UNBOUND | WQ_FREEZABLE, 0);
+ rproc_recovery_wq = alloc_ordered_workqueue("rproc_recovery_wq",
+ WQ_FREEZABLE, 0);
if (!rproc_recovery_wq) {
pr_err("remoteproc: creation of rproc_recovery_wq failed\n");
return -ENOMEM;
--
2.17.1
--
Thx and BRs,
Aiqun(Maria) Yu
