Turbulence for concurrency-managed workqueues [LWN.net]

By Jonathan Corbet
December 23, 2009

Tejun Heo's concurrency-managed workqueues patch was discussed here in October. This work has been progressing, with some of the associated clean-up patches being merged for 2.6.33; the main part of the work would appear to be on a path for merging in 2.6.34. Or maybe not: some developers are starting to express some qualms.

The loudest complaints come from Peter Zijlstra, who would rather see effort go into converting workqueue users to using threaded interrupt handlers instead. To developers like Peter, the new workqueues look like a bunch of new complexity which could create new problems (management of CPU-intensive workqueue tasks, for example) while failing to address other issues, including the locking problems which can plague workqueue users now.

Tejun has responded with a description of some of the problems being solved by the redone workqueues, concluding:

Shifting complexity out of peripheral code to better crafted and managed core code is the right thing to do and it will shift a lot of complexity out of peripheral codes.

That may actually be where some of the trouble lies: the patch set, in its current state, does not really demonstrate this shift in complexity. So Ingo Molnar has requested some example conversions that show the advantages of concurrency-managed workqueues:

For this particular patchset it should be possible to identify existing patterns of code in the existing code base of 6+ millions lines of Linux driver code that would make the advantages of this +2000 lines of core kernel code plain obvious. There were multiple claims of problems with the current abstractions - so there sure must be a way to show off the new code in a few places.

Tejun has indicated that he will work to provide this demonstration. Should the next version of the patch set prove convincing on this front, the new workqueues might still be on-track for 2.6.34.

(Log in to post comments)