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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
