Messages in this thread |  | | Date | Fri, 5 Sep 2014 16:11:50 +0900 | Subject | Re: [RFC v2 0/6] driver-core: add asynch probe support | From | 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
|  |