In the original wq implementation, a single threaded (ST) wq had one worker
thread system-wide and a multi threaded (MT) wq had one
worker thread per CPU and . A single MT wq needed to keep around the same
number of workers as the number of CPUs.
The kernel grew a lot of MT
wq users over the years and with the number of CPU cores continuously
rising, some systems saturated the default 32k PID space just booting
The legacy workqueue interface needed a facelift because of the folowing problems:
- Proliferation of kernel threads The original version of workqueues could, on a large system, run the kernel out of process IDs before user space ever gets a chance to run.
- Deadlocks Workqueues could also be subject to deadlocks if locking is not handled very carefully
- Unnecessary Context switches Workqueue threads contend with each other for the CPU, causing more context switches than are really necessary.
My mentor, Tejun Heo has provided that face lift in the form of his concurrency managed workqueues patch. This 19-part series massively reworks the workqueue code, addressing the shortcomings of the current workqueue subsystem. It’s a better solution since:
- Maintains compatibility with the original workqueue API.
- Uses per-CPU unified worker pools shared by all wq to provide flexible level of concurrency on demand without wasting a lot of resource.
- Automatically regulates worker pool and level of concurrency so that
the API users don’t need to worry about such details.
Hence, my outreachy project involved removing the deprecated instances of the legacy workqueue interface and moving them to the CMWQ interface.
More stats are available on http://lwn.net/Articles/393172/