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. -- 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>
