if flush_scheduled_work() is allegedly overkill, why do drivers use it?
working my way through work queues and read this in workqueue.h: /** * flush_scheduled_work - ensure that any scheduled work has run to completion. * * Forces execution of the kernel-global workqueue and blocks until its * completion. * * Think twice before calling this function! It's very easy to get into * trouble if you don't take great care. Either of the following situations * will lead to deadlock: * * One of the work items currently on the workqueue needs to acquire * a lock held by your code or its caller. * * Your code is running in the context of a work routine. * * They will be detected by lockdep when they occur, but the first might not * occur very often. It depends on what work items are on the workqueue and * what locks they need, which you have no control over. * * In most situations flushing the entire workqueue is overkill; you merely * need to know that a particular work item isn't queued and isn't running. * In such cases you should use cancel_delayed_work_sync() or * cancel_work_sync() instead. */ and yet, there are quite a few drivers that do just that: $ grep -rw flush_scheduled_work drivers drivers/scsi/scsi_scan.c: flush_scheduled_work(); drivers/scsi/qla2xxx/qla_target.c: flush_scheduled_work(); drivers/leds/leds-blinkm.c: flush_scheduled_work(); drivers/acpi/osl.c: * which invoke flush_scheduled_work/acpi_os_wait_events_complete drivers/staging/olpc_dcon/olpc_dcon.c: flush_scheduled_work(); drivers/staging/rtl8192u/r8192U_core.c:// flush_scheduled_work(); drivers/staging/wlan-ng/prism2usb.c: flush_scheduled_work(); drivers/staging/iio/light/tsl2563.c: flush_scheduled_work(); drivers/staging/iio/light/tsl2563.c: flush_scheduled_work(); drivers/staging/rtl8712/usb_intf.c: flush_scheduled_work(); drivers/message/fusion/mptscsih.c: flush_scheduled_work(); drivers/rtc/rtc-dev.c: flush_scheduled_work(); drivers/rtc/rtc-88pm860x.c: flush_scheduled_work(); drivers/misc/mei/main.c: flush_scheduled_work(); drivers/misc/mei/main.c: flush_scheduled_work(); ... snip, even more after this ... so what's up with that? it seems inconsistent to describe that kernel-wide routine as "overkill" while a number of drivers continue to use it. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
On Fri, Oct 19, 2012 at 10:12 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
working my way through work queues and read this in workqueue.h:
/** * flush_scheduled_work - ensure that any scheduled work has run to completion. * * Forces execution of the kernel-global workqueue and blocks until its * completion. * * Think twice before calling this function! It's very easy to get into * trouble if you don't take great care. Either of the following situations * will lead to deadlock: * * One of the work items currently on the workqueue needs to acquire * a lock held by your code or its caller. * * Your code is running in the context of a work routine. * * They will be detected by lockdep when they occur, but the first might not * occur very often. It depends on what work items are on the workqueue and * what locks they need, which you have no control over. * * In most situations flushing the entire workqueue is overkill; you merely * need to know that a particular work item isn't queued and isn't running. * In such cases you should use cancel_delayed_work_sync() or * cancel_work_sync() instead. */
and yet, there are quite a few drivers that do just that:
$ grep -rw flush_scheduled_work drivers drivers/scsi/scsi_scan.c: flush_scheduled_work(); drivers/scsi/qla2xxx/qla_target.c: flush_scheduled_work(); drivers/leds/leds-blinkm.c: flush_scheduled_work(); drivers/acpi/osl.c: * which invoke flush_scheduled_work/acpi_os_wait_events_complete drivers/staging/olpc_dcon/olpc_dcon.c: flush_scheduled_work(); drivers/staging/rtl8192u/r8192U_core.c:// flush_scheduled_work(); drivers/staging/wlan-ng/prism2usb.c: flush_scheduled_work(); drivers/staging/iio/light/tsl2563.c: flush_scheduled_work(); drivers/staging/iio/light/tsl2563.c: flush_scheduled_work(); drivers/staging/rtl8712/usb_intf.c: flush_scheduled_work(); drivers/message/fusion/mptscsih.c: flush_scheduled_work(); drivers/rtc/rtc-dev.c: flush_scheduled_work(); drivers/rtc/rtc-88pm860x.c: flush_scheduled_work(); drivers/misc/mei/main.c: flush_scheduled_work(); drivers/misc/mei/main.c: flush_scheduled_work(); ... snip, even more after this ...
so what's up with that? it seems inconsistent to describe that kernel-wide routine as "overkill" while a number of drivers continue to use it.
rday
Robert, I saw a thread about disk i/o that may relate. At least with disk buffers in the block layer, it appeared it was an all or nothing situation for flushing the queues. So if a upper level wanted to ensure write A completed prior to write B, the only option was: - write A (places data in the block queue) - flush buffers and write all data in the block queue regardless of source - write B (places data in the block queue) I gathered that several of the people in the thread were surprised at the lack of granularity, but no better solution was offered, nor even proposed for the future. Thus, I "assume" the calls you see in the block i/o stack are truly needed. Greg
On Fri, 19 Oct 2012, Greg Freemyer wrote:
I saw a thread about disk i/o that may relate. At least with disk buffers in the block layer, it appeared it was an all or nothing situation for flushing the queues. So if a upper level wanted to ensure write A completed prior to write B, the only option was:
- write A (places data in the block queue) - flush buffers and write all data in the block queue regardless of source - write B (places data in the block queue)
I gathered that several of the people in the thread were surprised at the lack of granularity, but no better solution was offered, nor even proposed for the future.
Thus, I "assume" the calls you see in the block i/o stack are truly needed.
i'm still not convinced of the logic here. i can see that while one can create one's own workqueue, there is a single kernel-wide work queue that you can take advantage of. but is that single kernel-wide WQ meant for things that are really important? or really trivial? and if some kernel subsystem truly needs a work queue, wouldn't it make sense to create its own? whoops, hang on, it appears that flush_scheduled_work() has been deprecated for a while: https://www.google.ca/webhp?sourceid=chrome-instant&ie=UTF-8#hl=en&output=se... it just hasn't gone away yet. i will read further ... rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
participants (2)
-
Greg Freemyer -
Robert P. J. Day