From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Widawsky Subject: Re: [PATCH] drm/i915: Allocate atomically in execbuf path Date: Tue, 26 Nov 2013 20:23:46 -0800 Message-ID: <20131127042346.GA601@bwidawsk.net> References: <1385513750-470-1-git-send-email-benjamin.widawsky@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail.bwidawsk.net (bwidawsk.net [166.78.191.112]) by gabe.freedesktop.org (Postfix) with ESMTP id EC9E6FAC48 for ; Tue, 26 Nov 2013 20:23:52 -0800 (PST) Content-Disposition: inline In-Reply-To: <1385513750-470-1-git-send-email-benjamin.widawsky@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org To: Ben Widawsky Cc: Daniel Vetter , Intel GFX List-Id: intel-gfx@lists.freedesktop.org On Tue, Nov 26, 2013 at 04:55:50PM -0800, Ben Widawsky wrote: > If we end up calling the shrinker, which in turn requires the OOM > killer, we may end up infinitely waiting for a process to die if the OOM > chooses. The case that this prevents occurs in execbuf. The forked > variants of gem_evict_everything is a good way to hit it. This is > exacerbated by Daniel's recent patch to give OOM precedence to the GEM > tests. > > It's a twisted form of a deadlock. > > What occurs is the following (assume just 2 procs) > 1. proc A gets to execbuf while out of memory, gets struct_mutex. > 2. OOM killer comes in and chooses proc B > 3. proc B closes it's fds, which requires struct mutex, blocks > 4, OOM killer waits for B to die before killing another process (this > part is speculative) > > Cc: Daniel Vetter > Cc: Chris Wilson > Signed-off-by: Ben Widawsky I'd still like to know if I am crazy, but I'm now trying to defer the stuff we do on file close without using any allocs. Just an update... -- Ben Widawsky, Intel Open Source Technology Center