All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: weili@codeaurora.org
Cc: linux-kernel@vger.kernel.org, vatsa@codeaurora.org
Subject: Re: [PATCH] driver-core: remove lock for platform devices during probe
Date: Tue, 25 Apr 2017 12:36:29 +0100	[thread overview]
Message-ID: <20170425113629.GB7191@kroah.com> (raw)
In-Reply-To: <677fb8f26419c4418a62d412a134edfc@codeaurora.org>

On Tue, Apr 25, 2017 at 04:43:33PM +0800, weili@codeaurora.org wrote:
> 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.

And why wasn't that information in the initial commit message?

And how much of a % is 140ms?  Why is a single driver taking that long
to initialize itself?

> > 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.

Don't you think that is also a problem?

> > 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

No, I mean the boot graph in pretty .svg format that the kernel can
output, with times and processes and everything.  Look in the tools
directory for more information, it will give you the exact timing for
your change before and after and show you exactly where you are taking
long periods of time.

You did use that, or something else to measure this somehow, right?

> > 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.

I know all about USB here :)

You did not answer my questions :(

greg k-h

  reply	other threads:[~2017-04-25 11:41 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-24  5:42 [PATCH] driver-core: remove lock for platform devices during probe Wei Li
2017-04-24  7:32 ` Greg Kroah-Hartman
2017-04-24  8:27   ` weili
2017-04-24  8:46     ` Greg Kroah-Hartman
2017-04-25  8:43       ` weili
2017-04-25 11:36         ` Greg Kroah-Hartman [this message]
2017-05-02  2:18           ` weili
2017-05-02 18:37             ` Greg Kroah-Hartman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170425113629.GB7191@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vatsa@codeaurora.org \
    --cc=weili@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.