All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Gupta, Sourab" <sourab.gupta@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"Wu, Jabin" <jabin.wu@intel.com>,
	"Woo, Insoo" <insoo.woo@intel.com>
Subject: Re: [RFC 1/8] drm/i915: Add a new PMU for handling non-OA counter data profiling requests
Date: Wed, 5 Aug 2015 09:40:25 +0000	[thread overview]
Message-ID: <1438767767.13551.35.camel@sourabgu-desktop> (raw)
In-Reply-To: <20150805092223.GE10387@nuc-i3427.alporthouse.com>

On Wed, 2015-08-05 at 09:22 +0000, Chris Wilson wrote:
> On Wed, Aug 05, 2015 at 11:25:37AM +0530, sourab.gupta@intel.com wrote:
> > +static void gen_buffer_destroy(struct drm_i915_private *i915)
> > +{
> > +	mutex_lock(&i915->dev->struct_mutex);
> > +	vunmap(i915->gen_pmu.buffer.addr);
> > +	i915_gem_object_ggtt_unpin(i915->gen_pmu.buffer.obj);
> > +	drm_gem_object_unreference(&i915->gen_pmu.buffer.obj->base);
> > +	mutex_unlock(&i915->dev->struct_mutex);
> > +
> > +	spin_lock(&i915->gen_pmu.lock);
> > +	i915->gen_pmu.buffer.obj = NULL;
> > +	i915->gen_pmu.buffer.gtt_offset = 0;
> > +	i915->gen_pmu.buffer.addr = NULL;
> > +	spin_unlock(&i915->gen_pmu.lock);
> 
> This ordering looks scary. At the very least it deserves a comment to
> explain why it is safe.
> 
> So what stops a second event being created while the first is being
> destroyed? I presume the perf events are exclusive? Or a refcounted
> singleton?
> -Chris
> 
Hi Chris,

Yes, the perf events are exclusive. This patch doesn't handle the
problem of exclusion fully. I intended to handle this problem in the
later patch in the series: 
http://lists.freedesktop.org/archives/intel-gfx/2015-August/072959.html
If you check here, a new event init checks whether obj is NULL (while
holding the spinlock), to see whether it is exclusive.
This is taken care of during the event destroy work fn, which assigns
obj to NULL (while holding spinlock), after it is done with everything.

Regards,
Sourab
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-08-05  9:40 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-05  5:55 [RFC 0/8] Introduce framework for forwarding generic non-OA performance sourab.gupta
2015-08-05  5:55 ` [RFC 1/8] drm/i915: Add a new PMU for handling non-OA counter data profiling requests sourab.gupta
2015-08-05  9:22   ` Chris Wilson
2015-08-05  9:40     ` Gupta, Sourab [this message]
2015-08-05  9:38   ` Chris Wilson
2015-08-05  9:45     ` Gupta, Sourab
2015-08-05  9:49       ` Gupta, Sourab
2015-08-05 11:08         ` Chris Wilson
2015-08-05  9:56       ` Chris Wilson
2015-08-05  5:55 ` [RFC 2/8] drm/i915: Add mechanism for forwarding the timestamp data through perf sourab.gupta
2015-08-05  9:55   ` Chris Wilson
2015-08-05  5:55 ` [RFC 3/8] drm/i915: Handle event stop and destroy for GPU commands submitted sourab.gupta
2015-08-05  5:55 ` [RFC 4/8] drm/i915: Insert commands for capturing timestamps in the ring sourab.gupta
2015-08-05  9:30   ` Chris Wilson
2015-08-05  9:54     ` Gupta, Sourab
2015-08-05  5:55 ` [RFC 5/8] drm/i915: Add support for forwarding ring id in sample metadata through perf sourab.gupta
2015-08-05  9:26   ` Chris Wilson
2015-08-05  5:55 ` [RFC 6/8] drm/i915: Add support for forwarding pid in timestamp " sourab.gupta
2015-08-05  5:55 ` [RFC 7/8] drm/i915: Add support for forwarding execbuffer tags in timestamp sample metadata sourab.gupta
2015-08-05  9:17   ` Chris Wilson
2015-08-05  9:29     ` Daniel Vetter
2015-08-05 13:59       ` Robert Bragg
2015-08-05 15:25         ` Daniel Vetter
2015-08-05 16:48           ` Robert Bragg
2015-08-05  5:55 ` [RFC 8/8] drm/i915: Support for retrieving MMIO register values alongwith timestamps through perf sourab.gupta
2015-08-05 10:03   ` Chris Wilson
2015-08-05 10:18     ` Gupta, Sourab
2015-08-05 10:30       ` Chris Wilson
2015-08-05 14:22         ` Gupta, Sourab
2015-08-05 20:19   ` Robert Bragg
  -- strict thread matches above, loose matches on Subject: below --
2015-07-15  8:51 [RFC 0/8] Introduce framework for forwarding generic non-OA performance sourab.gupta
2015-07-15  8:51 ` [RFC 1/8] drm/i915: Add a new PMU for handling non-OA counter data profiling requests sourab.gupta

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=1438767767.13551.35.camel@sourabgu-desktop \
    --to=sourab.gupta@intel.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=chris@chris-wilson.co.uk \
    --cc=insoo.woo@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jabin.wu@intel.com \
    /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.