Christoph Lameter wrote: > On Sat, 31 Oct 2015, Tetsuo Handa wrote: > > > Then, you need to update below description (or drop it) because > > patch 3/3 alone will not guarantee that the counters are up to date. > > The vmstat system does not guarantee that the counters are up to date > always. The whole point is the deferral of updates for performance > reasons. They are updated *at some point* within stat_interval. That needs > to happen and that is what this patchset is fixing. So, if you refer to the blocking of the execution of vmstat updates, description for patch 3/3 sould be updated to something like below? ---------- Since __GFP_WAIT memory allocations do not call schedule() when there is nothing to reclaim, and workqueue does not kick remaining workqueue items unless in-flight workqueue item calls schedule(), __GFP_WAIT memory allocation requests by workqueue items can block vmstat_update work item forever. Since zone_reclaimable() decision depends on vmstat counters to be up to dated, a silent lockup occurs because a workqueue item doing a __GFP_WAIT memory allocation request continues using outdated vmstat counters. In order to fix this problem, we need to allocate a dedicated workqueue for vmstat. Note that this patch itself does not fix lockup problem. Tejun will develop a patch which detects lockup situation and kick remaining workqueue items. ---------- -- 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>