if flush_scheduled_work() is allegedly overkill, why do drivers use it?
Robert P. J. Day
rpjday at crashcourse.ca
Fri Oct 19 18:14:55 EDT 2012
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=search&sclient=psy-ab&q=flush_scheduled_work%20deprecated&oq=&gs_l=&pbx=1&fp=7ac18a866ba087&bpcl=35466521&bav=on.2,or.r_gc.r_pw.r_cp.r_qf.&biw=1018&bih=912
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
========================================================================
More information about the Kernelnewbies
mailing list