[lkml]   [2014]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject[RFC v2 0/6] driver-core: add asynch probe support
From: "Luis R. Rodriguez" <>

Here's a complete reimplementation of asynch loading support, it
discards completely the hippie / pipe dream idea that we need asynch
loading of modules / subsystems in general and just addresses running
probe asynchronously. This respin is based on Tejun's recommendation
on how to treat the probe asynchronously, we avoid async_schedule()
completely and just peg a struct work_struct on the driver private
structure. This obviously also means we have to flush_work() before
the driver's own remove() is called, we do that too.

Tejun's concerns on this regressing some driver's scripts which expect
the device to be available after loading remains valid, and the only
thing we can do to help there is to annotate the expecations on the
use of this "feature" to driver users. Scripts should be not be relying
on the driver init anyway so that type of usage should be phased out
and they should be hunting in udev for things popping up.

I'm a bit concerned about this actually regressing load time on
drivers that use this though instead of just having the module
probe run off of finit_module() though. Even with a kthread alternative
at least Santosh (Cc'd) has noted a regression in terms of time it
takes to complete probe on cxgb4. I'll eventually get your exact
numbers, but for now its an obvious regression *with* kthreads,
this solution goes with:

queue_work(system_unbound_wq, async_probe_work)

This is surely going to make things even worse... We could
use system_highpri_wq, or change the scheduling priority, but
for that I'd prefer to get feedback and someone to decide what
the right choice (TM) should be.

It is very important to highlight that async probe was added here
in light of issues found on *two* domains now that creeped up in

0) some built-in drivers delaying init
1) systemd 30 second timeout

I have been exchanging some e-mails with Tetsuo about his
original proposed work around that started this work when the
systemd 30 second timeout issue creeped up first, this series
includes a slightly modified version of that work around
which should address the sigkill even without 786235ee merged.
There may be others -- and that needs to be witch hunted.
It would also now safely allow us to find drivers that run
over the limit without killing systems / modules. I think that's
probably the best thing to do for now -- as we sweep through and
find these, we could eventually nuke the WARN_ONCE() and completely
listen to the kill. For now its just causing more problems than
solving anything, but its a good reflection of balance of desires
and design between userspace / kernelspace.

Luis R. Rodriguez (6):
driver-core: generalize freeing driver private member
driver-core: add driver async_probe support
kthread: warn on kill signal if not OOM
cxgb4: use async probe
mptsas: use async probe
pata_marvell: use async probe

drivers/ata/pata_marvell.c | 1 +
drivers/base/base.h | 6 +++
drivers/base/bus.c | 72 ++++++++++++++++++++++---
drivers/base/dd.c | 4 ++
drivers/message/fusion/mptsas.c | 1 +
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 1 +
include/linux/device.h | 5 ++
kernel/kmod.c | 21 +++++++-
kernel/kthread.c | 19 +++++++
9 files changed, 122 insertions(+), 8 deletions(-)


 \ /
  Last update: 2014-09-05 09:01    [W:0.122 / U:1.732 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site