From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wilson Subject: Re: [PATCH] drm/i915: Wait for the mutex whilst the reaper runs Date: Wed, 10 Oct 2012 16:21:42 +0100 Message-ID: <84c8a8$62f5up@orsmga001.jf.intel.com> References: <1349867250-22808-1-git-send-email-chris@chris-wilson.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by gabe.freedesktop.org (Postfix) with ESMTP id 0E8E59F658 for ; Wed, 10 Oct 2012 08:22:12 -0700 (PDT) In-Reply-To: <1349867250-22808-1-git-send-email-chris@chris-wilson.co.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Wed, 10 Oct 2012 12:07:30 +0100, Chris Wilson wrote: > If the system is forced to start kswapd to recover pages, the system is > very starved. Fortunately, kswapd is its own process context and can > wait for the mutex. Note this doesn't survive inspection with lockdep due to dependency upon pfmemalloc_wait in the direct reclaim path - that is, it is possible for __GFP_FS allocations to wait indefinitely upon kswapd (who in turn may be waiting for the dev->struct_mutex held by the direct reclaimer). As we don't have complete control over all allocations made whilst holding the struct_mutex, we can't control the gfp_t to avoid the deadlock. -Chris -- Chris Wilson, Intel Open Source Technology Centre