Dave Chinner wrote: > On Thu, Jun 05, 2014 at 09:45:26PM +0900, Tetsuo Handa wrote: > > This means that, under rare circumstances, it is possible that all processes > > other than kswapd are trapped into too_many_isolated()/congestion_wait() loop > > while kswapd is sleeping because this loop assumes that somebody else shall > > wake up kswapd and kswapd shall perform operations for making > > too_many_isolated() to return 0. However, we cannot guarantee that kswapd is > > waken by somebody nor kswapd is not blocked by blocking operations inside > > shrinker functions (e.g. mutex_lock()). > > So what you are saying is that kswapd is having problems with > getting blocked on locks held by processes in direct reclaim? > > What are the stack traces that demonstrate such a dependency loop? If a normal task's GFP_KERNEL memory allocation called a shrinker function and the shrinker function does GFP_WAIT-able allocation with a mutex held, there is a possibility that kswapd is waken up due to GFP_WAIT-able allocation and kswapd calls the shrinker function, and the kswapd is blocked at trying to hold the same mutex inside the shrinker function, isn't it? Since ttm_dma_pool_shrink_count()/ttm_dma_pool_shrink_scan() holds a mutex and ttm_dma_pool_shrink_scan() does GFP_WAIT-able allocation, I think such a dependency loop is possible. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
