linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Luis R . Rodriguez" <mcgrof@suse.com>, Tejun Heo <tj@kernel.org>
Cc: 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: [PATCH v2 0/8] Asynchronous device/driver probing support
Date: Mon, 30 Mar 2015 16:20:02 -0700	[thread overview]
Message-ID: <1427757610-27882-1-git-send-email-dmitry.torokhov@gmail.com> (raw)

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.

Thanks,
Dmitry


             reply	other threads:[~2015-03-30 23:20 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-30 23:20 Dmitry Torokhov [this message]
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
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=1427757610-27882-1-git-send-email-dmitry.torokhov@gmail.com \
    --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;
as well as URLs for NNTP newsgroup(s).