Messages in this thread | | | Subject | Re: [PATCH] mm/vmscan: Do not block forever atshrink_inactive_list(). | From | Tetsuo Handa <> | Date | Fri, 6 Jun 2014 21:19:22 +0900 |
| |
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.
| |