RE: [PATCH] driver core: multithreaded probing - more parallelism control

["Huang, Ying" <ying.huang@intel.com>]

>-----Original Message-----
>From: Stefan Richter [mailto:stefanr@s5r6.in-berlin.de]
>> The queue number is kernel-global.
>
>Then there is an API required to allocate and deallocate exclusive
queue
>IDs.  This feels strange as a mechanism for (de-)serialization, and
>might introduce some bulk WRT code and data.

I think the queue IDs of different subsystem need not to be exclusive.
The subsystem can allocate queue IDs arbitrarily. If one queue ID is
shared between several subsystems, corresponding probing will be
serialized. This will slow down the probing unnecessarily, but there
will be no race condition.

The benefit of the mechanism is that the maximum parallelism of probing
can be control.

>Really, I don't believe there is anything else required from
subsystems'
>point of view than
>  - the possibility to keep plain serial driver matching/probing,
>  - to allow unrestricted parallelism,
>  - to mark devices whose child devices shall be matched/probed
>    serially.

Maybe.

>Should there be a subsystem which has more special demands on mixture
of
>parallelism and serialization, it can easily use private means to
>serialize certain parts of driver probes, for example with the familiar
>mechanism of mutexes.
>
>Or if need be, such a subsystem can implement its own threading model.
>The FireWire subsystem for example first fetches so-called
configuration
>ROMs from each node on a bus by means of asynchronous split
>transactions.  The ROMs are scanned for device properties and
>capabilities, and then drivers are matched/probed.  The new FireWire
>subsystem currently uses workqueue jobs to read the ROMs.  The old
>FireWire subsystem uses one kernel thread per bus.  Before the new
>FireWire subsystem was announced, I planned to let the bus kthread
spawn
>node kthreads which (1) fetch and scan ROMs and (2) match and probe
>drivers for each unit in a node.

I know nothing about FireWire. If I say something nonsense, please just
ignore it.

Whether is it possible that a new unit is inserted during probing
kthread is running. If it is possible, the probing kthread maybe ignore
the new inserted unit. So a kthread for this new unit should be created
upon inserting. And there must be some synchronization mechanism
provided. So, I think something like probing queue may be better than
raw kthread for this. And the bus scanning thread may need to exist
during system running, using the probing queue the bus scanning thread
can be created and destroyed on demanded too.

Thank you very much for your comment.

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