From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tejun Heo <tj@kernel.org>, "Luis R . Rodriguez" <mcgrof@suse.com>,
linux-kernel@vger.kernel.org,
Arjan van de Ven <arjan@linux.intel.com>,
Rusty Russell <rusty@rustcorp.com.au>,
Olof Johansson <olof@lixom.net>,
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Subject: Re: [PATCH v2 0/8] Asynchronous device/driver probing support
Date: Mon, 6 Apr 2015 09:22:51 -0700 [thread overview]
Message-ID: <20150406162251.GB36770@dtor-ws> (raw)
In-Reply-To: <20150331203949.GI9974@htj.duckdns.org>
On Tue, Mar 31, 2015 at 04:39:49PM -0400, Tejun Heo wrote:
> On Mon, Mar 30, 2015 at 04:20:02PM -0700, Dmitry Torokhov wrote:
> > This series is a combination of changes proposed by Luis a couple months
> > ago and implementation used by Chrome OS. The issue we are trying to solve
> > here is "slow" devices and drivers spending "too much time" in their probe()
> > methods and it affects:
> >
> > - overall kernel boot process when drivers are compiled into the kernel
> > and slow devices stall entire boot progress;
> > - systemd desire to time out module loading process.
> >
> > Unlike Luis' proposal we do make use of asycn_schedule() infrastructure
> > instead of using a dedicated workqueue, so all existing synchronization
> > points in kernel that wait for device registration still work the same.
> > Also, the asynchronous probing is done not only during driver registration
> > (i.e. when devices are probed asynchronously only if they are registered
> > before the driver), but also during device registration and deferred probe
> > handling. This way slow devices do not stall kernel boot even when drivers
> > are compiled into the kernel.
> >
> > The last patch is for adventurous people to try and force
> > fully-asynchronous boot. It works for me with limited success - I can boot
> > Rockhip-based box to userspace as long as I force serial to be sychronously
> > probed and ignore the fact that most devices are using "dummy" regulators
> > as regulator subsystem really expects regulators to be registered in
> > orderly fashion on OF-based systems.
> >
> > Changes from v1:
> >
> > - Changed verbage in change logs and code to emphasise that
> > PROBE_PREFER_ASYNCHRONOUS is a temporary measure and the end goal is
> > to enable asynchronous probing by default, as requested by Tejun.
>
> Looks good to me. Please feel free to add
>
> Acked-by: Tejun Heo <tj@kernel.org>
Greg, it would be great if it could make it in 4.1.
Thanks!
--
Dmitry
next prev parent reply other threads:[~2015-04-06 16:22 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-30 23:20 [PATCH v2 0/8] Asynchronous device/driver probing support Dmitry Torokhov
2015-03-30 23:20 ` [PATCH 1/8] module: add extra argument for parse_params() callback Dmitry Torokhov
2015-03-30 23:20 ` [PATCH 2/8] driver-core: add asynchronous probing support for drivers Dmitry Torokhov
2015-05-29 10:48 ` Tomeu Vizoso
2015-05-29 13:23 ` Tomeu Vizoso
2015-06-01 12:04 ` Tomeu Vizoso
2015-07-06 23:41 ` Dmitry Torokhov
2015-06-27 23:45 ` Dan Williams
2015-07-03 18:30 ` Luis R. Rodriguez
2015-07-06 23:33 ` Dmitry Torokhov
2015-03-30 23:20 ` [PATCH 3/8] driver-core: add driver module asynchronous probe support Dmitry Torokhov
2015-03-30 23:20 ` [PATCH 4/8] driver-core: enable drivers to opt-out of async probe Dmitry Torokhov
2015-03-30 23:20 ` [PATCH 5/8] driver-core: platform_driver_probe() must probe synchronously Dmitry Torokhov
2015-03-30 23:20 ` [PATCH 6/8] amd64_edac: enforce synchronous probe Dmitry Torokhov
2015-03-30 23:20 ` [PATCH 7/8] module: add core_param_unsafe Dmitry Torokhov
2015-03-30 23:20 ` [PATCH 8/8] driver-core: allow enabling async probing for all modules and builtins Dmitry Torokhov
2015-05-20 7:27 ` Greg Kroah-Hartman
2015-05-20 16:44 ` Dmitry Torokhov
2015-05-21 4:34 ` Greg Kroah-Hartman
2015-05-21 19:02 ` Luis R. Rodriguez
2015-03-31 20:39 ` [PATCH v2 0/8] Asynchronous device/driver probing support Tejun Heo
2015-04-06 16:22 ` Dmitry Torokhov [this message]
2015-04-06 17:45 ` Greg Kroah-Hartman
2015-05-18 21:48 ` Dmitry Torokhov
2015-05-19 0:53 ` 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=20150406162251.GB36770@dtor-ws \
--to=dmitry.torokhov@gmail.com \
--cc=arjan@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@suse.com \
--cc=olof@lixom.net \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=rusty@rustcorp.com.au \
--cc=tj@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox