Re: [PATCH] gpu/drm/ttm: Use mutex_lock_killable() for shrinker functions.

[Tetsuo Handa]

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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/