Re: [RFC v2 0/6] driver-core: add asynch probe support

[Tejun Heo]

Hello,

On Thu, Sep 04, 2014 at 11:37:21PM -0700, Luis R. Rodriguez wrote:
> 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.

Ummm... I really don't think we can say that.  This was one of the
supported ways to wait for the probing of pre-existing devices on
driver load.  We can't simply go and declare that "scripts should not
be relying on the driver init anyway".  We just can't do that.

> 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 shouldn't add any noticeable delays in probing.  If it does, we
should track down why that's happening and fix it.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/