| Message ID | 1616583698-6398-1-git-send-email-ylal@codeaurora.org |
|---|---|
| State | Accepted |
| Commit | e611f8cd8717c8fe7d4229997e6cd029a1465253 |
| Headers | show |
| Series | [V2] driver core: Use unbound workqueue for deferred probes | expand |
Hello: This patch was applied to qcom/linux.git (refs/heads/for-next): On Wed, 24 Mar 2021 16:31:38 +0530 you wrote: > Deferred probe usually runs only on pinned kworkers, which might take > longer time if a device contains multiple sub-devices. One such case > is of sound card on mobile devices, where we have good number of > mixers and controls per mixer. > > We observed boot up improvement - deferred probes take ~600ms when bound > to little core kworker and ~200ms when deferred probe is queued on > unbound wq. This is due to scheduler moving the worker running deferred > probe work to big CPUs. Without this change, we see the worker is running > on LITTLE CPU due to affinity. > > [...] Here is the summary with links: - [V2] driver core: Use unbound workqueue for deferred probes https://git.kernel.org/qcom/c/e611f8cd8717 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
diff --git a/drivers/base/dd.c b/drivers/base/dd.c index 9179825f..c9c174a 100644 --- a/drivers/base/dd.c +++ b/drivers/base/dd.c @@ -182,7 +182,7 @@ static void driver_deferred_probe_trigger(void) * Kick the re-probe thread. It may already be scheduled, but it is * safe to kick it again. */ - schedule_work(&deferred_probe_work); + queue_work(system_unbound_wq, &deferred_probe_work); } /**
Deferred probe usually runs only on pinned kworkers, which might take longer time if a device contains multiple sub-devices. One such case is of sound card on mobile devices, where we have good number of mixers and controls per mixer. We observed boot up improvement - deferred probes take ~600ms when bound to little core kworker and ~200ms when deferred probe is queued on unbound wq. This is due to scheduler moving the worker running deferred probe work to big CPUs. Without this change, we see the worker is running on LITTLE CPU due to affinity. Since kworker runs deferred probe of several devices, the locality may not be important. Also, init thread executing driver initcalls, can potentially migrate as it has cpu affinity set to all cpus.In addition to this, async probes use unbounded workqueue. So, using unbounded wq for deferred probes looks to be similar to these w.r.t. scheduling behavior. Signed-off-by: Yogesh Lal <ylal@codeaurora.org> --- Changes in v2: Updating the Changelog with issue description. drivers/base/dd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)