On Thu, Oct 22, 2015 at 11:09:44PM +0900, Tejun Heo wrote: > On Thu, Oct 22, 2015 at 08:39:11AM -0500, Christoph Lameter wrote: > > On Thu, 22 Oct 2015, Tetsuo Handa wrote: > > > > > The problem would be that the "struct task_struct" to execute vmstat_update > > > job does not exist, and will not be able to create one on demand because we > > > are stuck at __GFP_WAIT allocation. Therefore adding a dedicated kernel > > > thread for vmstat_update job would work. But ... > > > > Yuck. Can someone please get this major screwup out of the work queue > > subsystem? Tejun? > > Hmmm? Just use a dedicated workqueue with WQ_MEM_RECLAIM. If > concurrency management is a problem and there's something live-locking > for that work item (really?), WQ_CPU_INTENSIVE escapes it. If this is > a common occurrence that it makes sense to give vmstat higher > priority, set WQ_HIGHPRI. Oooh, HIGHPRI + CPU_INTENSIVE immediate scheduling guarantee got lost while converting HIGHPRI to a separate pool but guaranteeing immediate scheduling for CPU_INTENSIVE is trivial. If vmstat requires that, please 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>