Re: mm/slab: What is cache_reap work for?

[Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>]

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@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>