All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Widawsky <ben@bwidawsk.net>
To: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	Intel GFX <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/i915: Allocate atomically in execbuf path
Date: Tue, 26 Nov 2013 20:23:46 -0800	[thread overview]
Message-ID: <20131127042346.GA601@bwidawsk.net> (raw)
In-Reply-To: <1385513750-470-1-git-send-email-benjamin.widawsky@intel.com>

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 <daniel.vetter@ffwll.ch>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Ben Widawsky <ben@bwidawsk.net>

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

  parent reply	other threads:[~2013-11-27  4:23 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-27  0:55 [PATCH] drm/i915: Allocate atomically in execbuf path Ben Widawsky
2013-11-27  1:10 ` Ben Widawsky
2013-11-27  1:21   ` Ben Widawsky
2013-11-27  4:23 ` Ben Widawsky [this message]
2013-11-27  6:48   ` Daniel Vetter
2013-11-27  6:48   ` Ben Widawsky
2013-11-27  6:53 ` [PATCH] drm/i915: Optionally defer context closing Ben Widawsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131127042346.GA601@bwidawsk.net \
    --to=ben@bwidawsk.net \
    --cc=benjamin.widawsky@intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.