All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org, Ben Widawsky <ben@bwidawsk.net>,
	Eugeni Dodonov <eugeni.dodonov@intel.com>
Subject: Re: [PATCH 1/1] drm/i915: track first and last processes that touch gem objects
Date: Mon, 6 Feb 2012 17:15:44 +0100	[thread overview]
Message-ID: <20120206161544.GD4066@phenom.ffwll.local> (raw)
In-Reply-To: <c55c5d$1s237a@AZSMGA002.ch.intel.com>

On Fri, Feb 03, 2012 at 06:02:38PM +0000, Chris Wilson wrote:
> On Fri,  3 Feb 2012 12:43:25 -0200, Eugeni Dodonov <eugeni.dodonov@intel.com> wrote:
> > This allows to hopefully find out who was responsible for the GPU death.
> > We record the 1st and last process to touch each object, to keep track of
> > the process which created the object originally and the last process to
> > touch it.
> > 
> > To simplify post-mortem analysis, we also search for the processes names
> > when gathering the i915_error_state and when peeking at the list of active
> > gem objects in debugfs. This is not perfect for tracking all the
> > processes, as they can quit or die before their batchbuffers got executed,
> > but having to track them during the entire object lifetime would be
> > excessively memcpy hungry.
> 
> I think you've slightly missed here. Tracking who created a buffer is
> interesting and who last used it, but you really need to also track 
> on whose behalf the request (i.e. each batch) is executing.
> 
> For the goal of recording creator, you could just use:
> 
>   obj->creator = current ? current->pid : 0;
> 
> in i915_gem_object_init with 0 as the special value for objects created by
> the driver outside of process context. And similarly for i915_add_request,
> though I'd associate those with the owner of the file_priv.  The important
> point here is that a buffer may be associated with multiple batches
> submitted by one or more clients before a hang is detected, and so unless
> the dispatch pid is tracked you do not know who submitted the erroneous
> batch. (Even a batch may be submitted more than once by many clients,
> given sufficient pathology.) So adding the request queue to the
> i915_error_state would also be interesting, especially with the jiffie
> and ring->tail.
> 
> Also note that there is no direct link between i915_gem_fault() and usage
> of the object, the point at which you want to add the obj->last_used_by
> tracking to is domain management - which catches the usage of CPU
> mappings as well as move-to-active.

I'll second Chris here - I think the interesting stuff is to add some kind
of cheap ownership tracking, not who exactly created the buffer. The
latter is imo only really interesting for resource accounting, and that
would require it to be somewhat more solid. And we don't do any resource
accounting atm anyway.
-Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

  reply	other threads:[~2012-02-06 16:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-03 14:43 [PATCH 1/1] drm/i915: track first and last processes that touch gem objects Eugeni Dodonov
2012-02-03 14:53 ` Konstantin Belousov
2012-02-03 15:31   ` Eugeni Dodonov
2012-02-03 15:49     ` Konstantin Belousov
2012-02-03 18:02 ` Chris Wilson
2012-02-06 16:15   ` Daniel Vetter [this message]
2012-02-06 22:59     ` Eric Anholt
2012-02-07  8:49       ` 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=20120206161544.GD4066@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=ben@bwidawsk.net \
    --cc=chris@chris-wilson.co.uk \
    --cc=eugeni.dodonov@intel.com \
    --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.