On Thu 22-10-15 23:09:44, 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. Do I get it right that if vmstat_update has its own workqueue with WQ_MEM_RECLAIM then there is a _guarantee_ that the rescuer will always be able to process vmstat_update work from the requested CPU? That should be sufficient because vmstat_update doesn't sleep on allocation. I agree that this would be a more appropriate fix. -- Michal Hocko SUSE Labs -- 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>