Re: [RFC 1/8] drm/i915: Add a new PMU for handling non-OA counter data profiling requests

From: Chris Wilson <chris@chris-wilson.co.uk>
To: sourab.gupta@intel.com
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
	intel-gfx@lists.freedesktop.org, Jabin Wu <jabin.wu@intel.com>,
	Insoo Woo <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 10:22:23 +0100	[thread overview]
Message-ID: <20150805092223.GE10387@nuc-i3427.alporthouse.com> (raw)
In-Reply-To: <1438754144-20435-2-git-send-email-sourab.gupta@intel.com>

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

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx