Christoph Lameter wrote: > On Tue, 4 Jul 2017, Tetsuo Handa wrote: > > > Thank you for explanation. What I observed is that it seems that > > cache_reap work was not able to run because it used system_wq when > > the system was unable to allocate memory for new worker thread due to > > infinite too_many_isolated() loop in shrink_inactive_list(). > > Its ok for it not to run for awhile but that potentially traps memory. And > you want more memory to be freed. > > > I wondered whether cache_reap work qualifies as an mm_percpu_wq user > > if cache_reap work does something like what vmstat_work work does (e.g. > > update statistic counters which affect progress of memory allocation). > > But "calls other functions that are used during regular slab allocation" > > means cache_reap work cannot qualify as an mm_percpu_wq user... > > Well if you audit the functions called then you may be able to get there. > As far as I checked, it seems that the only operation that cache_reap work might sleep is cond_resched(). Thus, I think that cache_reap work can qualify as an mm_percpu_wq user. -- 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>
