Re: [PATCH] driver core: multithreaded probing - more parallelism control
On Fri, 22 Jun 2007 09:52:38 +, "Huang, Ying" <[EMAIL PROTECTED]> wrote: > On Thu, 2007-06-21 at 18:21 +0200, Stefan Richter wrote: > > Parallelism between subsystems may be interesting during boot == > > "coldplug", /if/ the machine has time-consuming devices to probe on > > /different/ types of buses. Of course some machines do the really > > time-consuming stuff on only one type of bus. Granted, parallelism > > betwen subsystems is not very interesting anymore later after boot == > > "hotplug". > > Yes. So I think there are two possible solution. > > 1. Creating one set of probing queues for each subsystem (maybe just the > subsystems need it), so the probing queue IDs are local to each > subsystem. > 2. There is only one set of probing queues in whole system. The probing > queue IDs are shared between subsystems. The subsystem can select a > random starting queue ID (maybe named as start_queue_id), and allocate > the queue IDs from that point on (start_queue_id + private_queue_id). So > the probability of queue ID sharing will be reduced. What should also be considered here is that we may want to have different numbers of queues per subsystem (fewer for those where probing is resource-heavy), but may want to restrict the total number of queues as well. Some throttling mechanism may be helpful here (so that a single subsystem cannot hog all queues while another is stuck with a single queue, or double usage of queues). In fact, throttling may be interesting for any subsystem using parallelism, especially if the number of devices may be huge and/or probing resource hungry. Cornelia - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] driver core: multithreaded probing - more parallelism control
On Fri, 22 Jun 2007 09:52:38 +, Huang, Ying [EMAIL PROTECTED] wrote: On Thu, 2007-06-21 at 18:21 +0200, Stefan Richter wrote: Parallelism between subsystems may be interesting during boot == coldplug, /if/ the machine has time-consuming devices to probe on /different/ types of buses. Of course some machines do the really time-consuming stuff on only one type of bus. Granted, parallelism betwen subsystems is not very interesting anymore later after boot == hotplug. Yes. So I think there are two possible solution. 1. Creating one set of probing queues for each subsystem (maybe just the subsystems need it), so the probing queue IDs are local to each subsystem. 2. There is only one set of probing queues in whole system. The probing queue IDs are shared between subsystems. The subsystem can select a random starting queue ID (maybe named as start_queue_id), and allocate the queue IDs from that point on (start_queue_id + private_queue_id). So the probability of queue ID sharing will be reduced. What should also be considered here is that we may want to have different numbers of queues per subsystem (fewer for those where probing is resource-heavy), but may want to restrict the total number of queues as well. Some throttling mechanism may be helpful here (so that a single subsystem cannot hog all queues while another is stuck with a single queue, or double usage of queues). In fact, throttling may be interesting for any subsystem using parallelism, especially if the number of devices may be huge and/or probing resource hungry. Cornelia - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] driver core: multithreaded probing - more parallelism control
Greg KH wrote: > I'm still not convinced that we need to add this kind of complexity to > the driver core, instead of just letting the individual driver > subsystems do this, if they want to do it. > > Especially as no subsystem wants to do this today :) Yes, it should first be shown (with subsystem conversions and runtime tests with, say, at least two different bus architectures) that features like this really are appropriately implemented as a driver core abstraction. I would lend a hand to put this to test, but I won't do this anymore with the old ieee1394 subsystem, and work on the new firewire subsystem will be focused on stabilization and feature completion in the short to mid term. -- Stefan Richter -=-=-=== -==- ==--- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] driver core: multithreaded probing - more parallelism control
On Wed, Jun 20, 2007 at 09:00:58PM +, Huang, Ying wrote: > Hi, > > This is a new version of multithreaded probing patch, with more > parallelism control added. > > There are more control over which devices and drivers will be probed > parallelized or serially. For example, in IEEE1394 subsystem, the > different "units" in one "node" can be probed serially while the > different "nodes" can be probed parallelized. > > The number of threads can be controlled through a kernel command line > parameters. > > The patch is against 2.6.22-rc5. The "wait_for_probes" function in the > patch comes from the original multithreaded probing patch. If I need do > anything because of it, please let me know. > > Any comment is welcome. I'm still not convinced that we need to add this kind of complexity to the driver core, instead of just letting the individual driver subsystems do this, if they want to do it. Especially as no subsystem wants to do this today :) thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] driver core: multithreaded probing - more parallelism control
On Wed, Jun 20, 2007 at 09:00:58PM +, Huang, Ying wrote: Hi, This is a new version of multithreaded probing patch, with more parallelism control added. There are more control over which devices and drivers will be probed parallelized or serially. For example, in IEEE1394 subsystem, the different units in one node can be probed serially while the different nodes can be probed parallelized. The number of threads can be controlled through a kernel command line parameters. The patch is against 2.6.22-rc5. The wait_for_probes function in the patch comes from the original multithreaded probing patch. If I need do anything because of it, please let me know. Any comment is welcome. I'm still not convinced that we need to add this kind of complexity to the driver core, instead of just letting the individual driver subsystems do this, if they want to do it. Especially as no subsystem wants to do this today :) thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] driver core: multithreaded probing - more parallelism control
Greg KH wrote: I'm still not convinced that we need to add this kind of complexity to the driver core, instead of just letting the individual driver subsystems do this, if they want to do it. Especially as no subsystem wants to do this today :) Yes, it should first be shown (with subsystem conversions and runtime tests with, say, at least two different bus architectures) that features like this really are appropriately implemented as a driver core abstraction. I would lend a hand to put this to test, but I won't do this anymore with the old ieee1394 subsystem, and work on the new firewire subsystem will be focused on stabilization and feature completion in the short to mid term. -- Stefan Richter -=-=-=== -==- ==--- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] driver core: multithreaded probing - more parallelism control
On Thu, 2007-06-21 at 18:21 +0200, Stefan Richter wrote: > Parallelism between subsystems may be interesting during boot == > "coldplug", /if/ the machine has time-consuming devices to probe on > /different/ types of buses. Of course some machines do the really > time-consuming stuff on only one type of bus. Granted, parallelism > betwen subsystems is not very interesting anymore later after boot == > "hotplug". Yes. So I think there are two possible solution. 1. Creating one set of probing queues for each subsystem (maybe just the subsystems need it), so the probing queue IDs are local to each subsystem. 2. There is only one set of probing queues in whole system. The probing queue IDs are shared between subsystems. The subsystem can select a random starting queue ID (maybe named as start_queue_id), and allocate the queue IDs from that point on (start_queue_id + private_queue_id). So the probability of queue ID sharing will be reduced. > (The old FireWire stack will re-enter the main loop of the bus scanning > thread sometime after a bus reset event signaled that nodes or units may > have appeared or disappeared. The new FireWire stack will schedule > respective scanning workqueue jobs after such an event.) I think the workqueue is better than kernel thread here. With kernel thread, the nodes and units may be needed to be scanned again and again for each unit/node if many units/nodes are appeared at almost the same time, while with workqueue, just schedule the jobs needed. And a workqueue like the probing queue whose thread can be created/destroyed on demand will save more resources than ordinary workqueue. :) Best Regards, Huang Ying - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] driver core: multithreaded probing - more parallelism control
Huang, Ying wrote: > 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. Parallelism between subsystems may be interesting during boot == "coldplug", /if/ the machine has time-consuming devices to probe on /different/ types of buses. Of course some machines do the really time-consuming stuff on only one type of bus. Granted, parallelism betwen subsystems is not very interesting anymore later after boot == "hotplug". [...] > Whether is it possible that a new unit is inserted during probing > kthread is running. Nodes and units on nodes may came and go at arbitrary points in time, and I'm sure similar things can be said about the majority of other bus architectures or network architectures. We take this into account. (The old FireWire stack will re-enter the main loop of the bus scanning thread sometime after a bus reset event signaled that nodes or units may have appeared or disappeared. The new FireWire stack will schedule respective scanning workqueue jobs after such an event.) -- Stefan Richter -=-=-=== -==- =-=-= http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] driver core: multithreaded probing - more parallelism control
>-Original Message- >From: Stefan Richter [mailto:[EMAIL PROTECTED] >> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] driver core: multithreaded probing - more parallelism control
Huang, Ying wrote: >> Is the queue number kernel-global or per subsystem? > > 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. 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. 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. If the old FireWire subsystem had a future, I would most certainly not use your mechanism but implement what you described. I am not sure about the new FireWire subsystem; there isn't much practical experience with it yet. -- Stefan Richter -=-=-=== -==- =-=-= http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] driver core: multithreaded probing - more parallelism control
Huang, Ying wrote: Is the queue number kernel-global or per subsystem? 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. 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. 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. If the old FireWire subsystem had a future, I would most certainly not use your mechanism but implement what you described. I am not sure about the new FireWire subsystem; there isn't much practical experience with it yet. -- Stefan Richter -=-=-=== -==- =-=-= http://arcgraph.de/sr/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] driver core: multithreaded probing - more parallelism control
-Original Message- From: Stefan Richter [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] driver core: multithreaded probing - more parallelism control
Huang, Ying wrote: 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. Parallelism between subsystems may be interesting during boot == coldplug, /if/ the machine has time-consuming devices to probe on /different/ types of buses. Of course some machines do the really time-consuming stuff on only one type of bus. Granted, parallelism betwen subsystems is not very interesting anymore later after boot == hotplug. [...] Whether is it possible that a new unit is inserted during probing kthread is running. Nodes and units on nodes may came and go at arbitrary points in time, and I'm sure similar things can be said about the majority of other bus architectures or network architectures. We take this into account. (The old FireWire stack will re-enter the main loop of the bus scanning thread sometime after a bus reset event signaled that nodes or units may have appeared or disappeared. The new FireWire stack will schedule respective scanning workqueue jobs after such an event.) -- Stefan Richter -=-=-=== -==- =-=-= http://arcgraph.de/sr/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] driver core: multithreaded probing - more parallelism control
On Thu, 2007-06-21 at 18:21 +0200, Stefan Richter wrote: Parallelism between subsystems may be interesting during boot == coldplug, /if/ the machine has time-consuming devices to probe on /different/ types of buses. Of course some machines do the really time-consuming stuff on only one type of bus. Granted, parallelism betwen subsystems is not very interesting anymore later after boot == hotplug. Yes. So I think there are two possible solution. 1. Creating one set of probing queues for each subsystem (maybe just the subsystems need it), so the probing queue IDs are local to each subsystem. 2. There is only one set of probing queues in whole system. The probing queue IDs are shared between subsystems. The subsystem can select a random starting queue ID (maybe named as start_queue_id), and allocate the queue IDs from that point on (start_queue_id + private_queue_id). So the probability of queue ID sharing will be reduced. (The old FireWire stack will re-enter the main loop of the bus scanning thread sometime after a bus reset event signaled that nodes or units may have appeared or disappeared. The new FireWire stack will schedule respective scanning workqueue jobs after such an event.) I think the workqueue is better than kernel thread here. With kernel thread, the nodes and units may be needed to be scanned again and again for each unit/node if many units/nodes are appeared at almost the same time, while with workqueue, just schedule the jobs needed. And a workqueue like the probing queue whose thread can be created/destroyed on demand will save more resources than ordinary workqueue. :) Best Regards, Huang Ying - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] driver core: multithreaded probing - more parallelism control
Hi,
This is a new version of multithreaded probing patch, with more
parallelism control added.
There are more control over which devices and drivers will be probed
parallelized or serially. For example, in IEEE1394 subsystem, the
different "units" in one "node" can be probed serially while the
different "nodes" can be probed parallelized.
The number of threads can be controlled through a kernel command line
parameters.
The patch is against 2.6.22-rc5. The "wait_for_probes" function in the
patch comes from the original multithreaded probing patch. If I need do
anything because of it, please let me know.
Any comment is welcome.
Best Regards,
Huang Ying
---
This patch add multithreaded probing with more parallelism control.
The device/driver probing is done on a probing queue, which is a
customized version of work queue, where the thread of probing queue will
come and go on demand. There is a queue No. for each probing queue. The
queue No. ranges from 0 to (unsigned short) ~0U, any queue No. can be
used by probing independent of the underlying thread number.
The device/driver probing is submitted to a probing queue though
"schedule_probe" function with probing queue No, a probing function and
corresponding parameter specified. The probing with same probing queue
No. will be done serially, while the probing with different probing
queue No. may be done parallelized.
"schedule_probe" is a general interface of multithreaded probing. While
convenient interfaces are as follow.
A field named "probe_queue_no" is added to "struct device", which
indicates probing queue No. on which the probing of the device will be
done. The subsystem can control the parallelism through this field. For
example, in IEEE1394 subsystems, the same probe_queue_no can be assigned
for different "units" in same "node" while different probe_queue_no can
be assigned to different "nodes".
Fields named "has_probe_queue" and "probe_queue_no" are added to "struct
device_driver". This let the probing queue can be controlled through
driver side too. If "has_probe_queue" is set, the "probe_queue_no" of
"struct device_driver" is used, otherwise that of "struct device" is
used.
There are other rules to control the parallelism.
1. The child device will not start probing until the probing of its
parent has been done.
2. The different drivers of same device will be probed serially.
If it is intended to separate the probing process of the device/driver
into synchronous part and asynchronous part, the ".probe" of "struct
device_driver" is used as the synchronous interface of device probing,
while the asynchronous part of probing can be submitted through
"schedule_probe" in ".probe" function. All the synchronous part will be
submitted with same probing queue number.
More strict serialization can be gotten through this mechanism if
needed. For example, if two USB driver is inserted into kernel
simultaneously, in original driver probing code, two USB device may be
probed simultaneously, while they will be probed serially if two device
has same probing queue No. in probing queue based probing code.
There is a problem of this multithreaded probing mechanism. There are
some code in kernel doing hardware access but not in the driver ".probe"
function, which may conflict with the multithreaded probiMore strict
serialization can be gotten through this mechanism if
needed. For example, if two USB driver is inserted into kernel
simultaneously, in original driver probing code, two USB device may be
probed simultaneously, while they will be probed serially if two device
has same probing queue No. in probing queue based probing code.
There is a problem of this multithreaded probing mechanism. There are
some code in kernel doing hardware access but not in the driver ".probe"
function, which may conflict with the multithreaded probing driver code.
A possible mechanism is executing those hardware access code in a
probing queue through "schedule_probe".ng driver code. A possible
mechanism is executing those hardware access code in a probing queue
through "schedule_probe".
Signed-off-by: Huang Ying <[EMAIL PROTECTED]>
---
drivers/base/dd.c | 182 ++---
include/linux/device.h | 27 ++-
2 files changed, 199 insertions(+), 10 deletions(-)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index b0088b0..a5cd629 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -23,6 +23,162 @@
#include "base.h"
#include "power/power.h"
+struct probe_queue {
+ spinlock_t lock;
+ struct list_head probe_list;
+ unsigned has_thread : 1;
+};
+
+struct simple_probe {
+ struct probe probe;
+ struct device *dev;
+ struct device_driver *drv;
+};
+
+static struct probe_queue *probe_queues;
+static atomic_t probe_count = ATOMIC_INIT(0);
+static DECLARE_WAIT_QUEUE_HEAD(probe_waitqueue);
+
+static int probe_thread_num = 1;
+
+static int __init set_probe_thread_num(char *str)
+{
+
Re: [PATCH] driver core: multithreaded probing - more parallelism control
On Wed, 2007-06-20 at 17:09 +0200, Stefan Richter wrote: > I'd call it probe_queue_number or maybe probe_queue_id. The term "no" > is ambiguous. Yes, I think probe_queue_id is better. > Is the queue number kernel-global or per subsystem? The queue number is kernel-global. I think this is easy to be implemented. And the serialization demand between subsystem can be satisfied too. > > + * @probe: probing infromation include probing function and parameter > ^^^ > typo: information Sorry, I will correct it in the next version. Best Regards, Huang Ying - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] driver core: multithreaded probing - more parallelism control
> Huang, Ying wrote: ... >> + * @probe: probing infromation include probing function and parameter > ^^^ > typo: information Also, the meaning of the rest of the sentence is unclear. -- Stefan Richter -=-=-=== -==- =-=-- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] driver core: multithreaded probing - more parallelism control
Huang, Ying wrote: > This is a new version of multithreaded probing patch, with more > parallelism control added. Thanks. (I'd like to try it out but will probably be busy with other stuff during the next few weeks.) ... > A field named "probe_queue_no" is added to "struct device", which I'd call it probe_queue_number or maybe probe_queue_id. The term "no" is ambiguous. > indicates probing queue No. on which the probing of the device will be > done. The subsystem can control the parallelism through this field. Is the queue number kernel-global or per subsystem? ... > + * schedule_probe - schedule a probing to be done later > + * @probe_queue_no: probing queue No. on which the probing will be done > + * @probe: probing infromation include probing function and parameter ^^^ typo: information -- Stefan Richter -=-=-=== -==- =-=-- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] driver core: multithreaded probing - more parallelism control
Huang, Ying wrote: This is a new version of multithreaded probing patch, with more parallelism control added. Thanks. (I'd like to try it out but will probably be busy with other stuff during the next few weeks.) ... A field named probe_queue_no is added to struct device, which I'd call it probe_queue_number or maybe probe_queue_id. The term no is ambiguous. indicates probing queue No. on which the probing of the device will be done. The subsystem can control the parallelism through this field. Is the queue number kernel-global or per subsystem? ... + * schedule_probe - schedule a probing to be done later + * @probe_queue_no: probing queue No. on which the probing will be done + * @probe: probing infromation include probing function and parameter ^^^ typo: information -- Stefan Richter -=-=-=== -==- =-=-- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] driver core: multithreaded probing - more parallelism control
Huang, Ying wrote: ... + * @probe: probing infromation include probing function and parameter ^^^ typo: information Also, the meaning of the rest of the sentence is unclear. -- Stefan Richter -=-=-=== -==- =-=-- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] driver core: multithreaded probing - more parallelism control
On Wed, 2007-06-20 at 17:09 +0200, Stefan Richter wrote: I'd call it probe_queue_number or maybe probe_queue_id. The term no is ambiguous. Yes, I think probe_queue_id is better. Is the queue number kernel-global or per subsystem? The queue number is kernel-global. I think this is easy to be implemented. And the serialization demand between subsystem can be satisfied too. + * @probe: probing infromation include probing function and parameter ^^^ typo: information Sorry, I will correct it in the next version. Best Regards, Huang Ying - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] driver core: multithreaded probing - more parallelism control
Hi,
This is a new version of multithreaded probing patch, with more
parallelism control added.
There are more control over which devices and drivers will be probed
parallelized or serially. For example, in IEEE1394 subsystem, the
different units in one node can be probed serially while the
different nodes can be probed parallelized.
The number of threads can be controlled through a kernel command line
parameters.
The patch is against 2.6.22-rc5. The wait_for_probes function in the
patch comes from the original multithreaded probing patch. If I need do
anything because of it, please let me know.
Any comment is welcome.
Best Regards,
Huang Ying
---
This patch add multithreaded probing with more parallelism control.
The device/driver probing is done on a probing queue, which is a
customized version of work queue, where the thread of probing queue will
come and go on demand. There is a queue No. for each probing queue. The
queue No. ranges from 0 to (unsigned short) ~0U, any queue No. can be
used by probing independent of the underlying thread number.
The device/driver probing is submitted to a probing queue though
schedule_probe function with probing queue No, a probing function and
corresponding parameter specified. The probing with same probing queue
No. will be done serially, while the probing with different probing
queue No. may be done parallelized.
schedule_probe is a general interface of multithreaded probing. While
convenient interfaces are as follow.
A field named probe_queue_no is added to struct device, which
indicates probing queue No. on which the probing of the device will be
done. The subsystem can control the parallelism through this field. For
example, in IEEE1394 subsystems, the same probe_queue_no can be assigned
for different units in same node while different probe_queue_no can
be assigned to different nodes.
Fields named has_probe_queue and probe_queue_no are added to struct
device_driver. This let the probing queue can be controlled through
driver side too. If has_probe_queue is set, the probe_queue_no of
struct device_driver is used, otherwise that of struct device is
used.
There are other rules to control the parallelism.
1. The child device will not start probing until the probing of its
parent has been done.
2. The different drivers of same device will be probed serially.
If it is intended to separate the probing process of the device/driver
into synchronous part and asynchronous part, the .probe of struct
device_driver is used as the synchronous interface of device probing,
while the asynchronous part of probing can be submitted through
schedule_probe in .probe function. All the synchronous part will be
submitted with same probing queue number.
More strict serialization can be gotten through this mechanism if
needed. For example, if two USB driver is inserted into kernel
simultaneously, in original driver probing code, two USB device may be
probed simultaneously, while they will be probed serially if two device
has same probing queue No. in probing queue based probing code.
There is a problem of this multithreaded probing mechanism. There are
some code in kernel doing hardware access but not in the driver .probe
function, which may conflict with the multithreaded probiMore strict
serialization can be gotten through this mechanism if
needed. For example, if two USB driver is inserted into kernel
simultaneously, in original driver probing code, two USB device may be
probed simultaneously, while they will be probed serially if two device
has same probing queue No. in probing queue based probing code.
There is a problem of this multithreaded probing mechanism. There are
some code in kernel doing hardware access but not in the driver .probe
function, which may conflict with the multithreaded probing driver code.
A possible mechanism is executing those hardware access code in a
probing queue through schedule_probe.ng driver code. A possible
mechanism is executing those hardware access code in a probing queue
through schedule_probe.
Signed-off-by: Huang Ying [EMAIL PROTECTED]
---
drivers/base/dd.c | 182 ++---
include/linux/device.h | 27 ++-
2 files changed, 199 insertions(+), 10 deletions(-)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index b0088b0..a5cd629 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -23,6 +23,162 @@
#include base.h
#include power/power.h
+struct probe_queue {
+ spinlock_t lock;
+ struct list_head probe_list;
+ unsigned has_thread : 1;
+};
+
+struct simple_probe {
+ struct probe probe;
+ struct device *dev;
+ struct device_driver *drv;
+};
+
+static struct probe_queue *probe_queues;
+static atomic_t probe_count = ATOMIC_INIT(0);
+static DECLARE_WAIT_QUEUE_HEAD(probe_waitqueue);
+
+static int probe_thread_num = 1;
+
+static int __init set_probe_thread_num(char *str)
+{
+ get_option(str, probe_thread_num);
+ if
