Tetsuo Handa wrote:
> From e314a1a1583e585d062dfc30c8aad8bf5380510b Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx>
> Date: Mon, 19 May 2014 18:43:21 +0900
> Subject: [PATCH] gpu/drm/ttm: Use mutex_lock_killable() for shrinker functions.
>
> I can observe that RHEL7 environment stalls with 100% CPU usage when a
> certain type of memory pressure is given. While the shrinker functions
> are called by shrink_slab() before the OOM killer is triggered, the stall
> lasts for many minutes.
>
> I added debug printk() and observed that many threads are blocked for more
> than 10 seconds at ttm_dma_pool_shrink_count()/ttm_dma_pool_shrink_scan()
> functions. Since the kswapd can call these functions later, the current
> thread can return from these functions as soon as chosen by the OOM killer.
>
> This patch changes "mutex_lock();" to "if (mutex_lock_killable()) return ...;"
> so that any threads can promptly give up. (By the way, as far as I tested,
> changing to "if (!mutex_trylock()) return ...;" likely shortens the duration
> of stall. Maybe we don't need to wait for mutex if someone is already calling
> these functions.)
>
While discussing about XFS problem, I got a question. Is it OK (from point
of view of reentrant) to use mutex_lock() or mutex_lock_killable() inside
shrinker's entry point functions? Can senario shown below possible?
(1) kswapd is doing memory reclaim which does not need to hold mutex.
(2) Someone in GFP_KERNEL context (not kswapd) calls
ttm_dma_pool_shrink_count() and then calls ttm_dma_pool_shrink_scan()
from direct reclaim path.
(3) Inside ttm_dma_pool_shrink_scan(), GFP_KERNEL allocation is issued
while mutex is held by the someone.
(4) GFP_KERNEL allocation cannot be completed immediately due to memory
pressure.
(5) kswapd calls ttm_dma_pool_shrink_count() which need to hold mutex.
(6) Inside ttm_dma_pool_shrink_count(), kswapd is blocked waiting for
mutex held by the someone, and the someone is waiting for GFP_KERNEL
allocation to complete, but GFP_KERNEL allocation cannot be completed
until mutex held by the someone is released?
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
