[PATCH] driver core: support bus manage deferred probe
From: Zhang Ning
deferred probe will be hanlded by deferred_probe_initcall,
starts at late_initcall.
this is too late to handle deferred probe, this will block kernel exec
to userspace, make kernel initial time longer.
if we know when required resources are ready for a list of devices,
related deferred drivers can be probe earlier.
add these kinds of drivers into logical list,
eg, bus_type->deferred_probe_pending_list,
then it can be easily handled by bus driver.
with analysis above:
add manage_deferred to struct bus_type
add deferred_probe_pending_list to struct bus_type
when manage_deferred is true, deferred probe will be
manage by bus.
Signed-off-by: Zhang Ning
---
drivers/base/bus.c | 3 ++-
drivers/base/dd.c | 24 +---
include/linux/device.h | 5 +
3 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index 8bfd27ec73d6..ca8eaf7565db 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -898,7 +898,8 @@ int bus_register(struct bus_type *bus)
retval = bus_add_groups(bus, bus->bus_groups);
if (retval)
goto bus_groups_fail;
-
+ if (bus->manage_deferred)
+ INIT_LIST_HEAD(&bus->deferred_probe_pending_list);
pr_debug("bus: '%s': registered\n", bus->name);
return 0;
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 1435d7281c66..926e57f8dd2f 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -82,10 +82,8 @@ static void deferred_probe_debug(struct device *dev)
dev_name(dev), duration);
}
-/*
- * deferred_probe_work_func() - Retry probing devices in the active list.
- */
-static void deferred_probe_work_func(struct work_struct *work)
+
+void process_deferred_probe(struct list_head *list)
{
struct device *dev;
struct device_private *private;
@@ -102,8 +100,8 @@ static void deferred_probe_work_func(struct work_struct
*work)
* from under our feet.
*/
mutex_lock(&deferred_probe_mutex);
- while (!list_empty(&deferred_probe_active_list)) {
- private = list_first_entry(&deferred_probe_active_list,
+ while (!list_empty(list)) {
+ private = list_first_entry(list,
typeof(*dev->p), deferred_probe);
dev = private->device;
list_del_init(&private->deferred_probe);
@@ -136,6 +134,15 @@ static void deferred_probe_work_func(struct work_struct
*work)
}
mutex_unlock(&deferred_probe_mutex);
}
+
+/*
+ * deferred_probe_work_func() - Retry probing devices in the active list.
+ */
+static void deferred_probe_work_func(struct work_struct *work)
+{
+ process_deferred_probe(&deferred_probe_active_list);
+}
+
static DECLARE_WORK(deferred_probe_work, deferred_probe_work_func);
static void driver_deferred_probe_add(struct device *dev)
@@ -143,7 +150,10 @@ static void driver_deferred_probe_add(struct device *dev)
mutex_lock(&deferred_probe_mutex);
if (list_empty(&dev->p->deferred_probe)) {
dev_dbg(dev, "Added to deferred list\n");
- list_add_tail(&dev->p->deferred_probe,
&deferred_probe_pending_list);
+ if (dev->bus->manage_deferred)
+ list_add_tail(&dev->p->deferred_probe,
&dev->bus->deferred_probe_pending_list);
+ else
+ list_add_tail(&dev->p->deferred_probe,
&deferred_probe_pending_list);
}
mutex_unlock(&deferred_probe_mutex);
}
diff --git a/include/linux/device.h b/include/linux/device.h
index 055a69dbcd18..2f70f3124d18 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -143,6 +143,9 @@ struct bus_type {
struct lock_class_key lock_key;
bool need_parent_lock;
+
+ bool manage_deferred;
+ struct list_head deferred_probe_pending_list;
};
extern int __must_check bus_register(struct bus_type *bus);
@@ -151,6 +154,8 @@ extern void bus_unregister(struct bus_type *bus);
extern int __must_check bus_rescan_devices(struct bus_type *bus);
+extern void process_deferred_probe(struct list_head *list);
+
/* iterator helpers for buses */
struct subsys_dev_iter {
struct klist_iter ki;
--
2.17.1
[PATCH] init: no need to wait device probe
From: Zhang Ning
there are 2 reasons for no need to wait device probe
reason 1:
mount root device is very late in kernel initial stage.
all initcalls are finished. that means most of probe functions
are returned.
and deferred probe are also finished by late_initcall.
only async probe driver are possible in probing.
no block devices, device-mapper or nfs are use async probe.
so no need to wait device probe.
reason 2:
let's check dd.c, probe_count is increased and decreased only
in really_probe, and when really_probe returns, probe_count
always be 0.
when someone really wants to wait device-B probe.
but code looks like:
thread-1: thread-2:
probe device-A; wait_for_device_probe();
msleep(30);
probe device-B
when device-A probe finishes, thread-2 will be wakeup,
but device-B is not probed.
wait_for_device_probe can't make sure the device you want is probed.
based on above 2 reasons, no need to wait for device probe.
Signed-off-by: Zhang Ning
---
init/do_mounts.c| 9 -
init/do_mounts_md.c | 2 --
2 files changed, 11 deletions(-)
diff --git a/init/do_mounts.c b/init/do_mounts.c
index 7cf4f6dafd5f..a9fb2ad44964 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -555,15 +555,6 @@ void __init prepare_namespace(void)
ssleep(root_delay);
}
- /*
-* wait for the known devices to complete their probing
-*
-* Note: this is a potential source of long boot delays.
-* For example, it is not atypical to wait 5 seconds here
-* for the touchpad of a laptop to initialize.
-*/
- wait_for_device_probe();
-
md_run_setup();
if (saved_root_name[0]) {
diff --git a/init/do_mounts_md.c b/init/do_mounts_md.c
index 3f733c760a8c..4aab3492e71d 100644
--- a/init/do_mounts_md.c
+++ b/init/do_mounts_md.c
@@ -292,8 +292,6 @@ static void __init autodetect_raid(void)
printk(KERN_INFO "md: Waiting for all devices to be available before
autodetect\n");
printk(KERN_INFO "md: If you don't use raid, use raid=noautodetect\n");
- wait_for_device_probe();
-
fd = sys_open("/dev/md0", 0, 0);
if (fd >= 0) {
sys_ioctl(fd, RAID_AUTORUN, raid_autopart);
--
2.14.2
[PATCH] init: no need to wait device probe
From: Zhang Ning
there are 2 reasons for no need to wait device probe
reason 1:
mount root device is very late in kernel initial stage.
all initcalls are finished. that means most of probe functions
are returned.
and deferred probe are also finished by late_initcall.
only async probe driver are possible in probing.
no block devices, device-mapper or nfs are use async probe.
so no need to wait device probe.
reason 2:
let's check dd.c, probe_count is increased and decreased only
in really_probe, and when really_probe returns, probe_count
always be 0.
when someone really wants to wait device-B probe.
but code looks like:
thread-1: thread-2:
probe device-A; wait_for_device_probe();
msleep(30);
probe device-B
when device-A probe finishes, thread-2 will be wakeup,
but device-B is not probed.
wait_for_device_probe can't make sure the device you want is probed.
based on above 2 reasons, no need to wait for device probe.
Signed-off-by: Zhang Ning
---
init/do_mounts.c| 9 -
init/do_mounts_md.c | 2 --
2 files changed, 11 deletions(-)
diff --git a/init/do_mounts.c b/init/do_mounts.c
index 7cf4f6dafd5f..a9fb2ad44964 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -555,15 +555,6 @@ void __init prepare_namespace(void)
ssleep(root_delay);
}
- /*
-* wait for the known devices to complete their probing
-*
-* Note: this is a potential source of long boot delays.
-* For example, it is not atypical to wait 5 seconds here
-* for the touchpad of a laptop to initialize.
-*/
- wait_for_device_probe();
-
md_run_setup();
if (saved_root_name[0]) {
diff --git a/init/do_mounts_md.c b/init/do_mounts_md.c
index 3f733c760a8c..4aab3492e71d 100644
--- a/init/do_mounts_md.c
+++ b/init/do_mounts_md.c
@@ -292,8 +292,6 @@ static void __init autodetect_raid(void)
printk(KERN_INFO "md: Waiting for all devices to be available before
autodetect\n");
printk(KERN_INFO "md: If you don't use raid, use raid=noautodetect\n");
- wait_for_device_probe();
-
fd = sys_open("/dev/md0", 0, 0);
if (fd >= 0) {
sys_ioctl(fd, RAID_AUTORUN, raid_autopart);
--
2.14.2
[PATCH] x86/smpboot: set topology CPU mask before use.
From: Zhang Ning
we detect topology CPU mask in tsc is used before it is set, it leads
to longer bootup time.
let's check the code.
smpboot.c:smp_callin()
---> calibarate.c:calibrate_delay()
---> tsc.c: calibrate_delay_is_known()
---> topology_core_cpumask(): read topology CPU mask
---> set_cpu_sibling_map(raw_smp_processor_id())
---> cpumask_set_cpu(cpu, topology_core_cpumask(cpu));
from the calling chain, we know topology CPU mask is used before it
actually set.
So move set_cpu_sibling_map before calibrate_delay.
Change-Id: I4eb8facb8751fe7aa2c6d2eac32437266d92ec00
Signed-off-by: Zhang Ning
---
arch/x86/kernel/smpboot.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 36171bcd91f8..acee1ca3ef43 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -181,6 +181,12 @@ static void smp_callin(void)
smp_store_cpu_info(cpuid);
/*
+* This must be done before setting cpu_online_mask
+* or calling notify_cpu_starting.
+*/
+ set_cpu_sibling_map(raw_smp_processor_id());
+
+ /*
* Get our bogomips.
* Update loops_per_jiffy in cpu_data. Previous call to
* smp_store_cpu_info() stored a value that is close but not as
@@ -190,11 +196,7 @@ static void smp_callin(void)
cpu_data(cpuid).loops_per_jiffy = loops_per_jiffy;
pr_debug("Stack at about %p\n", &cpuid);
- /*
-* This must be done before setting cpu_online_mask
-* or calling notify_cpu_starting.
-*/
- set_cpu_sibling_map(raw_smp_processor_id());
+
wmb();
notify_cpu_starting(cpuid);
--
2.11.0
