[Intel-gfx] [RFC 1/8] drm/i915: Add a new PMU for handling non-OA counter data profiling requests
Chris Wilson
chris at chris-wilson.co.uk
Wed Aug 5 02:22:23 PDT 2015
On Wed, Aug 05, 2015 at 11:25:37AM +0530, sourab.gupta at 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
More information about the Intel-gfx
mailing list