lkml.org 
[lkml]   [2017]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] driver-core: remove lock for platform devices during probe
Hi Greg K-H,

On 2017-04-24 16:46, Greg Kroah-Hartman wrote:

> And does it really reduce boot time? What are the numbers?
Yes, it really reduce boot time. After making most time-consuming
platform driver using async probe
and also applying this patch, we see the driver run in parallel with
others and saving 140ms.


> Why do you have so many platform devices and not "real bus" devices?
We are working on an ARM soc. There are many host controllers
implemented as platform devices.


> What does the boot graph look like when you run with and without this
> patch?
Without the patch, the boot graph is like this:
CPU0: platform driver1 probe -> lock parent -> do probe staff ->
unlock parent -> probe finish
CPU1: platform driver2 probe -> wait for lock on
parent -> lock parent -> do probe -> unlock parent -> probe
finish

With the patch, the boot graph is like this:
CPU0: platform driver1 probe -> do probe staff -> probe finish
CPU1: platform drvier2 probe -> do probe staff -> probe finish


> Why is the platform bus so "special" to warrant this? Should we
> perhaps make this
> an option for any bus to enable/disable?
The lock on parent was first introduced by USB guys in following
commit

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/drivers/base/dd.c?id=bf74ad5bc41727d5f2f1c6bedb2c1fac394de731
This may be useful for real bus devices such as USB and they think
overhead of acquiring a lock is not large.
But since platfrom bus is virtual, the lock is not necessary. Removing
it for platform devices will make
driver running in parallel and benefit boot time.

Best Regards
Wei

\
 
 \ /
  Last update: 2017-04-25 10:44    [W:0.109 / U:0.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site