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 17:21:27 -0800	[thread overview]
Message-ID: <20131127012127.GA1981@bwidawsk.net> (raw)
In-Reply-To: <20131127011037.GA1889@bwidawsk.net>

On Tue, Nov 26, 2013 at 05:10:38PM -0800, Ben Widawsky wrote:
> 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)
> > 
> 
> It appears that by itself, this patch is insufficient to prevent the
> failure when run in piglit. Before I go on a wild goose chase of finding
> all allocations, maybe I'll give people a chance to chime in. The
> symptom is the same always, OOM, procs can't die because struct_mutex is
> held.
> 

too late on the goose chase. vma allocation was the missing bit.

> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
> > ---
> >  drivers/gpu/drm/i915/i915_gem.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> > index fb2d548..a60894d 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -1842,12 +1842,12 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object *obj)
> >  	BUG_ON(obj->base.read_domains & I915_GEM_GPU_DOMAINS);
> >  	BUG_ON(obj->base.write_domain & I915_GEM_GPU_DOMAINS);
> >  
> > -	st = kmalloc(sizeof(*st), GFP_KERNEL);
> > +	st = kmalloc(sizeof(*st), GFP_NOWAIT);
> >  	if (st == NULL)
> >  		return -ENOMEM;
> >  
> >  	page_count = obj->base.size / PAGE_SIZE;
> > -	if (sg_alloc_table(st, page_count, GFP_KERNEL)) {
> > +	if (sg_alloc_table(st, page_count, GFP_NOWAIT)) {
> >  		kfree(st);
> >  		return -ENOMEM;
> >  	}
> > -- 
> > 1.8.4.2
> > 
> 
> -- 
> Ben Widawsky, Intel Open Source Technology Center
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ben Widawsky, Intel Open Source Technology Center

  reply	other threads:[~2013-11-27  1:21 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 [this message]
2013-11-27  4:23 ` Ben Widawsky
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=20131127012127.GA1981@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.