Christoph Lameter wrote: > On Tue, 27 Jun 2017, Tetsuo Handa wrote: > > > I hit an unable to invoke the OOM killer lockup shown below. According to > > "cpus=2 node=0 flags=0x0 nice=0" part, it seems that cache_reap (in mm/slab.c) > > work stuck waiting for disk_events_workfn (in block/genhd.c) work to complete. > > Cache reaping in SLAB is the expiration of objects since they are deemed > to be cache cold after while. Reaping is a tick driven worker thread that > calls other functions that are used during regular slab allocation and > freeing. Maybe someone added code that can cause deadlocks if invoked from > the tick? 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(). 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... -- 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>
