Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Tuesday 02 November 2010 08:39:45 Hans Petter Selasky wrote: On Monday 01 November 2010 22:14:49 John Baldwin wrote: On Monday, November 01, 2010 3:54:59 pm Hans Petter Selasky wrote: Hi! I've wrapped up an outline patch for what needs to be done to integrate the USB process framework into the kernel taskqueue system in a more direct way that to wrap it. The limitation of the existing taskqueue system is that it only guarantees execution at a given priority level. USB requires more. USB also requires a guarantee that the last task queued task also gets executed last. This is for example so that a deferred USB detach event does not happen before any pending deferred I/O for example in case of multiple occurring events. Mostly this new feature is targeted for GPIO-alike system using slow busses like the USB. Typical use case: 2 tasks to program GPIO on. 2 tasks to program GPIO off. Example: a) taskqueue_enqueue_odd(sc-sc_taskqueue, sc-sc_task_on[0], sc- sc_task_on[1]); b) taskqueue_enqueue_odd(sc-sc_taskqueue, sc-sc_task_off[0], sc- sc_task_off[1]); No matter how the call ordering of code-line a) and b), we are always guaranteed that the last queued state on or off is reached before the head of the taskqueue empties. In lack of a better name, the new function was called taskqueue_enqueue_odd [some people obviously think that USB processes are odd, but not taskqueues :-)] It feels like this should be something you could manage with a state machine internal to USB rather than forcing that state into the taskqueue code itself. Hi John, No, this is not possible without keeping my own queue, which I want to avoid. By state-machine you mean remembering the last state as a separate variable and checking that in the task-callback, right? Yes, I do that in addition to the new queuing mechanism. A task barrier does not solve my problem. The barrier in my case is always last in the queue. I need to pull out previously queued tasks and put them last. That is currently not supported. I do this because I don't want to have a FIFO signalling model, and a neither want the pure taskqueue, which only ensures execution, not order of execution when at the same priority. Another issue: Won't the barrier model lead to blocking the caller once the task in question is being issued the second time? --HPS If you wanted a simple barrier task (where a barrier task is always queued at the tail of the list and all subsequent tasks are queued after the barrier task) then I would be fine with adding that. You could manage this without having to alter the task KBI by having the taskqueue maintain a separate pointer to the current barrier task and always enqueue entries after that task (the barrier would be NULL before a barrier is queued, and set to NULL when a barrier executes). I think this sort of semantic is a bit simpler and also used in other parts of the tree (e.g. in bio queues). Any more comments on this matter or someone still doing review? --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Mon, Nov 1, 2010 at 1:15 PM, Hans Petter Selasky hsela...@c2i.net wrote: On Monday 01 November 2010 21:07:29 Matthew Fleming wrote: On Mon, Nov 1, 2010 at 12:54 PM, Hans Petter Selasky hsela...@c2i.net wrote: Hi! I've wrapped up an outline patch for what needs to be done to integrate the USB process framework into the kernel taskqueue system in a more direct way that to wrap it. The limitation of the existing taskqueue system is that it only guarantees execution at a given priority level. USB requires more. USB also requires a guarantee that the last task queued task also gets executed last. This is for example so that a deferred USB detach event does not happen before any pending deferred I/O for example in case of multiple occurring events. Mostly this new feature is targeted for GPIO-alike system using slow busses like the USB. Typical use case: 2 tasks to program GPIO on. 2 tasks to program GPIO off. Example: a) taskqueue_enqueue_odd(sc-sc_taskqueue, sc-sc_task_on[0], sc- sc_task_on[1]); b) taskqueue_enqueue_odd(sc-sc_taskqueue, sc-sc_task_off[0], sc- sc_task_off[1]); No matter how the call ordering of code-line a) and b), we are always guaranteed that the last queued state on or off is reached before the head of the taskqueue empties. In lack of a better name, the new function was called taskqueue_enqueue_odd [some people obviously think that USB processes are odd, but not taskqueues :-)] I'd like to make sure I understand the USB requirements. (1) does USB need the task priority field? Many taskqueue(9) consumers do not. No, USB does not need a task priority field, but a sequence field associated with the task and task queue head to figure out which task was queued first without having to scan all the tasks queued. (2) if there was a working taskqueue_remove(9) that removed the task if pending or returned error if the task was currently running, would that be sufficient to implement the required USB functionality? (assuming that taskqueue_enqueue(9) put all tasks with equal priority in order of queueing). No, not completely. See comment above. I also need information about which task was queued first, or else I have to keep this information separately, which again, confuse people. The more layers the more confusion? I don't follow why keeping the information about which task was queued first privately rather than having taskqueue(9) maintain it is confusing. So far, USB seems to be the only taskqueue consumer which needs this information, so it makes a lot more sense to me for it to be USB private. To my mind, there's primary operations, and secondary ones. A secondary operation can be built from the primary ones. It reads to me that, if there was a taskqueue_cancel(9) (and there is in Jeff's OFED branch) then you could build the functionality you want (and maybe you don't need cancel, even). While there is sometimes an argument for making secondary operations available in a library, in this case you need extra data which most other taskqueue consumers do not. That would break the KBI. That is another argument in favor of keeping the implementation private to USB. Thanks, matthew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Thursday 04 November 2010 14:55:09 Matthew Fleming wrote: On Mon, Nov 1, 2010 at 1:15 PM, Hans Petter Selasky hsela...@c2i.net wrote: On Monday 01 November 2010 21:07:29 Matthew Fleming wrote: On Mon, Nov 1, 2010 at 12:54 PM, Hans Petter Selasky hsela...@c2i.net wrote: Hi! I've wrapped up an outline patch for what needs to be done to integrate the USB process framework into the kernel taskqueue system in a more direct way that to wrap it. The limitation of the existing taskqueue system is that it only guarantees execution at a given priority level. USB requires more. USB also requires a guarantee that the last task queued task also gets executed last. This is for example so that a deferred USB detach event does not happen before any pending deferred I/O for example in case of multiple occurring events. Mostly this new feature is targeted for GPIO-alike system using slow busses like the USB. Typical use case: 2 tasks to program GPIO on. 2 tasks to program GPIO off. Example: a) taskqueue_enqueue_odd(sc-sc_taskqueue, sc-sc_task_on[0], sc- sc_task_on[1]); b) taskqueue_enqueue_odd(sc-sc_taskqueue, sc-sc_task_off[0], sc- sc_task_off[1]); No matter how the call ordering of code-line a) and b), we are always guaranteed that the last queued state on or off is reached before the head of the taskqueue empties. In lack of a better name, the new function was called taskqueue_enqueue_odd [some people obviously think that USB processes are odd, but not taskqueues :-)] I'd like to make sure I understand the USB requirements. (1) does USB need the task priority field? Many taskqueue(9) consumers do not. No, USB does not need a task priority field, but a sequence field associated with the task and task queue head to figure out which task was queued first without having to scan all the tasks queued. (2) if there was a working taskqueue_remove(9) that removed the task if pending or returned error if the task was currently running, would that be sufficient to implement the required USB functionality? (assuming that taskqueue_enqueue(9) put all tasks with equal priority in order of queueing). No, not completely. See comment above. I also need information about which task was queued first, or else I have to keep this information separately, which again, confuse people. The more layers the more confusion? Hi, I don't follow why keeping the information about which task was queued first privately rather than having taskqueue(9) maintain it is confusing. So far, USB seems to be the only taskqueue consumer which needs this information, so it makes a lot more sense to me for it to be USB private. Probably I can check which task is pending when I queue them and store that in a separate variable. Still I need a way to remove a task from the queue, which becomes very slow due to the fact that STAILQ() is used. To my mind, there's primary operations, and secondary ones. A secondary operation can be built from the primary ones. That is right, if there is a way to remove a task from a queue without draining. It reads to me that, if there was a taskqueue_cancel(9) (and there is in Jeff's OFED branch) then you could build the functionality you want (and maybe you don't need cancel, even). While there is sometimes an argument for making secondary operations available in a library, in this case you need extra data which most other taskqueue consumers do not. That would break the KBI. That is another argument in favor of keeping the implementation private to USB. The only reason I want to break the KBI is because it is slow to remove a task from the taskqueue using STAILQ's when you don't know the previous task- element in the queue. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Thursday, November 04, 2010 9:55:09 am Matthew Fleming wrote: On Mon, Nov 1, 2010 at 1:15 PM, Hans Petter Selasky hsela...@c2i.net wrote: On Monday 01 November 2010 21:07:29 Matthew Fleming wrote: On Mon, Nov 1, 2010 at 12:54 PM, Hans Petter Selasky hsela...@c2i.net wrote: Hi! I've wrapped up an outline patch for what needs to be done to integrate the USB process framework into the kernel taskqueue system in a more direct way that to wrap it. The limitation of the existing taskqueue system is that it only guarantees execution at a given priority level. USB requires more. USB also requires a guarantee that the last task queued task also gets executed last. This is for example so that a deferred USB detach event does not happen before any pending deferred I/O for example in case of multiple occurring events. Mostly this new feature is targeted for GPIO-alike system using slow busses like the USB. Typical use case: 2 tasks to program GPIO on. 2 tasks to program GPIO off. Example: a) taskqueue_enqueue_odd(sc-sc_taskqueue, sc-sc_task_on[0], sc- sc_task_on[1]); b) taskqueue_enqueue_odd(sc-sc_taskqueue, sc-sc_task_off[0], sc- sc_task_off[1]); No matter how the call ordering of code-line a) and b), we are always guaranteed that the last queued state on or off is reached before the head of the taskqueue empties. In lack of a better name, the new function was called taskqueue_enqueue_odd [some people obviously think that USB processes are odd, but not taskqueues :-)] I'd like to make sure I understand the USB requirements. (1) does USB need the task priority field? Many taskqueue(9) consumers do not. No, USB does not need a task priority field, but a sequence field associated with the task and task queue head to figure out which task was queued first without having to scan all the tasks queued. (2) if there was a working taskqueue_remove(9) that removed the task if pending or returned error if the task was currently running, would that be sufficient to implement the required USB functionality? (assuming that taskqueue_enqueue(9) put all tasks with equal priority in order of queueing). No, not completely. See comment above. I also need information about which task was queued first, or else I have to keep this information separately, which again, confuse people. The more layers the more confusion? I don't follow why keeping the information about which task was queued first privately rather than having taskqueue(9) maintain it is confusing. So far, USB seems to be the only taskqueue consumer which needs this information, so it makes a lot more sense to me for it to be USB private. To my mind, there's primary operations, and secondary ones. A secondary operation can be built from the primary ones. It reads to me that, if there was a taskqueue_cancel(9) (and there is in Jeff's OFED branch) then you could build the functionality you want (and maybe you don't need cancel, even). While there is sometimes an argument for making secondary operations available in a library, in this case you need extra data which most other taskqueue consumers do not. That would break the KBI. That is another argument in favor of keeping the implementation private to USB. My sense is that I certainly agree. The fact that you can't think of a good name for the operation certainly indicates that it is not generic. Unfortunately, I don't really understand the problem that is being solved. I do agree that due to the 'pending' feature and automatic-coalescing of task enqueue operations, taskqueues do not lend themselves to a barrier operation. -- John Baldwin ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Thursday 04 November 2010 15:29:51 John Baldwin wrote: (and there is in Jeff's OFED branch) Is there a link to this branch? I would certainly have a look at his work and re-base my patch. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Thu, Nov 4, 2010 at 11:41 AM, Hans Petter Selasky hsela...@c2i.net wrote: On Thursday 04 November 2010 15:29:51 John Baldwin wrote: (and there is in Jeff's OFED branch) Is there a link to this branch? I would certainly have a look at his work and re-base my patch. It's on svn.freebsd.org: http://svn.freebsd.org/viewvc/base/projects/ofed/head/sys/kern/subr_taskqueue.c?view=log http://svn.freebsd.org/viewvc/base?view=revisionrevision=209422 For the purpose of speed, I'm not opposed to breaking the KBI by using a doubly-linked TAILQ, but I don't think the difference will matter all that often (perhaps I'm wrong and some taskqueues have dozens of pending tasks?) Thanks, matthew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Thursday 04 November 2010 20:01:57 Matthew Fleming wrote: For the purpose of speed, I'm not opposed to breaking the KBI by using a doubly-linked TAILQ, but I don't think the difference will matter all that often (perhaps I'm wrong and some taskqueues have dozens of pending tasks?) Hi, In my case we are talking about 10-15 tasks at maximum. But still (10*9) / 2 = 45 iterations is much more than 2 steps to do the unlink. Anyway. I will have a look at your work and suggest a new patch for my needs. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Thursday 04 November 2010 20:01:57 Matthew Fleming wrote: On Thu, Nov 4, 2010 at 11:41 AM, Hans Petter Selasky hsela...@c2i.net wrote: On Thursday 04 November 2010 15:29:51 John Baldwin wrote: (and there is in Jeff's OFED branch) Is there a link to this branch? I would certainly have a look at his work and re-base my patch. It's on svn.freebsd.org: http://svn.freebsd.org/viewvc/base/projects/ofed/head/sys/kern/subr_taskque ue.c?view=log http://svn.freebsd.org/viewvc/base?view=revisionrevision=209422 For the purpose of speed, I'm not opposed to breaking the KBI by using a doubly-linked TAILQ, but I don't think the difference will matter all that often (perhaps I'm wrong and some taskqueues have dozens of pending tasks?) Thanks, matthew At first look I see that I need a non-blocking version of: taskqueue_cancel( At the point in the code where these functions are called I cannot block. Is this impossible to implement? --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB 3.0 Fails To Attach Western Digital My Book 3.0
On Saturday 23 October 2010 15:37:55 Michael Martin wrote: On 10/23/2010 00:23, Hans Petter Selasky wrote: On Saturday 23 October 2010 02:07:59 Michael Martin wrote: On 10/21/2010 01:29, Michael Martin wrote: Thanks for the new USB 3.0 effort! I'm testing it out on 9.0-CURRENT amd64. The controller seems to find a 2.0 usb stick fine. However, when I plug in a Western Digital 3.0 drive, the device fails to attach. The WD drive attaches fine when plugging into a 2.0 port on the motherboard. Controller info: xh...@pci0:5:0:0: class=0x0c0330 card=0x chip=0x01941033 rev=0x03 hdr=0x00 vendor = 'NEC Electronics Hong Kong' class = serial bus subclass = USB bar [10] = type Memory, range 64, base 0xfbbfe000, size 8192, enabled cap 01[50] = powerspec 3 supports D0 D3 current D0 cap 05[70] = MSI supports 8 messages, 64 bit cap 11[90] = MSI-X supports 8 messages in map 0x10 cap 10[a0] = PCI-Express 2 endpoint max data 128(128) link x1(x1) ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0003[140] = Serial 1 ecap 0018[150] = unknown 1 WD 3.0 Drive Info ( while plugged into the 2.0 port ): ugen3.4:My Book 3.0 Western Digital at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0210 bDeviceClass = 0x bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x0040 idVendor = 0x1058 idProduct = 0x1123 bcdDevice = 0x1010 iManufacturer = 0x0001Western Digital iProduct = 0x0002My Book 3.0 iSerialNumber = 0x0003XXXRemovedXXX bNumConfigurations = 0x0001 Output when plugging in the Western Digital 3.0 into the 3.0 port: Oct 21 01:03:54 gandalf root: Unknown USB device: vendor 0x1058 product 0x1123 bus uhub4 Oct 21 01:03:54 gandalf kernel: ugen4.2:Western Digital at usbus4 Oct 21 01:03:54 gandalf kernel: umass0:Western Digital My Book 3.0, class 0/0, rev 3.00/10.10, addr 1 on usbus4 Oct 21 01:03:54 gandalf kernel: umass0: SCSI over Bulk-Only; quirks = 0x Oct 21 01:03:55 gandalf kernel: umass0:9:0:-1: Attached to scbus9 Oct 21 01:03:57 gandalf root: ZFS: zpool I/O failure, zpool=wd3.1 error=28 Oct 21 01:03:57 gandalf last message repeated 2 times Oct 21 01:03:57 gandalf root: ZFS: vdev I/O failure, zpool=wd3.1 path= offset= size= error= Oct 21 01:04:03 gandalf kernel: ugen4.2:Western Digital at usbus4 (disconnected) Oct 21 01:04:03 gandalf kernel: umass0: at uhub4, port 2, addr 1 (disconnected) Oct 21 01:04:03 gandalf kernel: (da0:umass-sim0:0:0:0): lost device Oct 21 01:04:03 gandalf kernel: (da0:umass-sim0:0:0:0): got CAM status 0xa Oct 21 01:04:03 gandalf kernel: (da0:umass-sim0:0:0:0): fatal error, failed to attach to device Oct 21 01:04:03 gandalf kernel: (da0:umass-sim0:0: Oct 21 01:04:03 gandalf kernel: 0:0): removing device entry Oct 21 01:04:14 gandalf root: ZFS: zpool I/O failure, zpool=wd3.1 error=28 Oct 21 01:04:14 gandalf last message repeated 2 times Oct 21 01:04:14 gandalf root: ZFS: vdev I/O failure, zpool=wd3.1 path= offset= size= error= Output when plugging in the WD 3.0 into the 2.0 port: Oct 21 01:15:20 gandalf root: Unknown USB device: vendor 0x1058 product 0x1123 bus uhub3 Oct 21 01:15:20 gandalf kernel: ugen3.4:Western Digital at usbus3 Oct 21 01:15:20 gandalf kernel: umass0:Western Digital My Book 3.0, class 0/0, rev 2.10/10.10, addr 4 on usbus3 Oct 21 01:15:20 gandalf kernel: umass0: SCSI over Bulk-Only; quirks = 0x Oct 21 01:15:21 gandalf kernel: umass0:9:0:-1: Attached to scbus9 Oct 21 01:15:28 gandalf kernel: da0 at umass-sim0 bus 0 scbus9 target 0 lun 0 Oct 21 01:15:28 gandalf kernel: da0:WD My Book 3.0 1123 1010 Fixed Direct Access SCSI-4 device Oct 21 01:15:28 gandalf kernel: da0: 40.000MB/s transfers Oct 21 01:15:28 gandalf kernel: da0: 953867MB (1953519616 512 byte sectors: 255H 63S/T 121600C) Output when plugging in 2.0 device into the 3.0 port: Oct 21 01:09:54 gandalf root: Unknown USB device: vendor 0x090c product 0x1000 bus uhub4 Oct 21 01:09:54 gandalf kernel: ugen4.2:USB at usbus4 Oct 21 01:09:54 gandalf kernel: umass1:USB Flash Disk, class 0/0, rev 2.00/11.00, addr 1 on usbus4 Oct 21 01:09:54 gandalf kernel: umass1: SCSI over Bulk-Only; quirks = 0x Oct 21 01:09:55 gandalf kernel: umass1:10:1:-1: Attached to scbus10 Oct 21 01:09:56 gandalf kernel: (probe0:umass-sim1:1:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 Oct 21 01:09:56 gandalf kernel: (probe0:umass-sim1:1:0:0): CAM status: SCSI Status Error Oct 21 01:09:56 gandalf kernel: (probe0:umass-sim1:1:0:0): SCSI status: Check Condition Oct 21 01:09:56 gandalf kernel: (probe0:umass-sim1:1:0:0): SCSI sense: UNIT ATTENTION asc:28,0 (Not ready to ready change, medium
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Thu, Nov 4, 2010 at 12:11 PM, Hans Petter Selasky hsela...@c2i.net wrote: On Thursday 04 November 2010 20:01:57 Matthew Fleming wrote: On Thu, Nov 4, 2010 at 11:41 AM, Hans Petter Selasky hsela...@c2i.net wrote: On Thursday 04 November 2010 15:29:51 John Baldwin wrote: (and there is in Jeff's OFED branch) Is there a link to this branch? I would certainly have a look at his work and re-base my patch. It's on svn.freebsd.org: http://svn.freebsd.org/viewvc/base/projects/ofed/head/sys/kern/subr_taskque ue.c?view=log http://svn.freebsd.org/viewvc/base?view=revisionrevision=209422 For the purpose of speed, I'm not opposed to breaking the KBI by using a doubly-linked TAILQ, but I don't think the difference will matter all that often (perhaps I'm wrong and some taskqueues have dozens of pending tasks?) Thanks, matthew At first look I see that I need a non-blocking version of: taskqueue_cancel( At the point in the code where these functions are called I cannot block. Is this impossible to implement? It depends on whether the queue uses a MTX_SPIN or MTX_DEF. It is not possible to determine whether a task is running without taking the taskqueue lock. And it is certainly impossible to dequeue a task without the lock that was used to enqueue it. However, a variant that dequeued if the task was still pending, and returned failure otherwise (rather than sleeping) is definitely possible. Thanks, matthew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Thursday 04 November 2010 21:11:38 Matthew Fleming wrote: On Thu, Nov 4, 2010 at 12:11 PM, Hans Petter Selasky hsela...@c2i.net wrote: On Thursday 04 November 2010 20:01:57 Matthew Fleming wrote: On Thu, Nov 4, 2010 at 11:41 AM, Hans Petter Selasky hsela...@c2i.net wrote: On Thursday 04 November 2010 15:29:51 John Baldwin wrote: (and there is in Jeff's OFED branch) Is there a link to this branch? I would certainly have a look at his work and re-base my patch. It's on svn.freebsd.org: http://svn.freebsd.org/viewvc/base/projects/ofed/head/sys/kern/subr_task que ue.c?view=log http://svn.freebsd.org/viewvc/base?view=revisionrevision=209422 For the purpose of speed, I'm not opposed to breaking the KBI by using a doubly-linked TAILQ, but I don't think the difference will matter all that often (perhaps I'm wrong and some taskqueues have dozens of pending tasks?) Thanks, matthew At first look I see that I need a non-blocking version of: taskqueue_cancel( At the point in the code where these functions are called I cannot block. Is this impossible to implement? It depends on whether the queue uses a MTX_SPIN or MTX_DEF. It is not possible to determine whether a task is running without taking the taskqueue lock. And it is certainly impossible to dequeue a task without the lock that was used to enqueue it. However, a variant that dequeued if the task was still pending, and returned failure otherwise (rather than sleeping) is definitely possible. I think that if a task is currently executing, then there should be a drain method for that. I.E. two methods: One to stop and one to cancel/drain. Can you implement this? --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote: On Thursday 04 November 2010 21:11:38 Matthew Fleming wrote: On Thu, Nov 4, 2010 at 12:11 PM, Hans Petter Selasky hsela...@c2i.net wrote: On Thursday 04 November 2010 20:01:57 Matthew Fleming wrote: On Thu, Nov 4, 2010 at 11:41 AM, Hans Petter Selasky hsela...@c2i.net wrote: On Thursday 04 November 2010 15:29:51 John Baldwin wrote: (and there is in Jeff's OFED branch) Is there a link to this branch? I would certainly have a look at his work and re-base my patch. It's on svn.freebsd.org: http://svn.freebsd.org/viewvc/base/projects/ofed/head/sys/kern/subr_task que ue.c?view=log http://svn.freebsd.org/viewvc/base?view=revisionrevision=209422 For the purpose of speed, I'm not opposed to breaking the KBI by using a doubly-linked TAILQ, but I don't think the difference will matter all that often (perhaps I'm wrong and some taskqueues have dozens of pending tasks?) Thanks, matthew At first look I see that I need a non-blocking version of: taskqueue_cancel( At the point in the code where these functions are called I cannot block. Is this impossible to implement? It depends on whether the queue uses a MTX_SPIN or MTX_DEF. It is not possible to determine whether a task is running without taking the taskqueue lock. And it is certainly impossible to dequeue a task without the lock that was used to enqueue it. However, a variant that dequeued if the task was still pending, and returned failure otherwise (rather than sleeping) is definitely possible. I think that if a task is currently executing, then there should be a drain method for that. I.E. two methods: One to stop and one to cancel/drain. Can you implement this? I agree, this would also be consistent with the callout_*() API if you had both stop() and drain() methods. -- John Baldwin ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin j...@freebsd.org wrote: On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote: I think that if a task is currently executing, then there should be a drain method for that. I.E. two methods: One to stop and one to cancel/drain. Can you implement this? I agree, this would also be consistent with the callout_*() API if you had both stop() and drain() methods. Here's my proposed code. Note that this builds but is not yet tested. Implement a taskqueue_cancel(9), to cancel a task from a queue. Requested by: hps Original code: jeff MFC after: 1 week http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff Thanks, matthew ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
