On Thu, Oct 22, 2015 at 09:25:49AM -0500, Christoph Lameter wrote: > On Thu, 22 Oct 2015, Tejun Heo wrote: > > > On Thu, Oct 22, 2015 at 09:23:54AM -0500, Christoph Lameter wrote: > > > I guess we need that otherwise vm statistics are not updated while worker > > > threads are blocking on memory reclaim. > > > > And the blocking one is just constantly running? > > I was told that there is just one task struct so additional work queue > items cannot be processed while waiting? lol, no, what it tries to do is trying to keep the number of RUNNING workers at minimum so that minimum number of workers can be used and work items are executed back-to-back on the same workers. The moment a work item blocks, the next worker kicks in and starts executing the next work item in line. The only way to hang the execution for a work item w/ WQ_MEM_RECLAIM is to create a cyclic dependency on another work item and keep that work item busy wait. Workqueue thinks that work item is making progress as it's running and doesn't schedule the next one. (I was misremembering here) HIGHPRI originally was implemented head-queueing on the same pool followed by immediate execution, so could get around cases where this could happen, but that got lost while converting it to a separate pool. I can introduce another flag to bypass concurrency management if necessary (it's kinda trivial) but busy-waiting cyclic dependency is a pretty unusual thing. If this is actually a legit busy-waiting cyclic dependency, just let me know. Thanks. -- tejun -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>