public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
* [PATCH] drm/i915: Add a tracepoint for using a semaphore
@ 2013-08-26 12:46 Chris Wilson
  2013-08-26 13:20 ` Ville Syrjälä
  0 siblings, 1 reply; 7+ messages in thread
From: Chris Wilson @ 2013-08-26 12:46 UTC (permalink / raw)
  To: intel-gfx

So that we can find the callers who introduce a ring stall. A single
ring stall is not too unwelcome, the right issue becomes when they start
to interlock and prevent any concurrent work. That, however, is a little
tricker to detect with a mere tracepoint!

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
 drivers/gpu/drm/i915/i915_gem.c   |  2 ++
 drivers/gpu/drm/i915/i915_trace.h | 19 +++++++++++++++++++
 2 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 85537d1..0122278 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2698,6 +2698,8 @@ i915_gem_object_sync(struct drm_i915_gem_object *obj,
 	if (ret)
 		return ret;
 
+	trace_i915_gem_object_sync(obj, to);
+
 	ret = to->sync_to(to, from, seqno);
 	if (!ret)
 		/* We use last_read_seqno because sync_to()
diff --git a/drivers/gpu/drm/i915/i915_trace.h b/drivers/gpu/drm/i915/i915_trace.h
index feaacbb..728c43b 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -33,6 +33,25 @@ TRACE_EVENT(i915_gem_object_create,
 	    TP_printk("obj=%p, size=%u", __entry->obj, __entry->size)
 );
 
+TRACE_EVENT(i915_gem_object_sync,
+	    TP_PROTO(struct drm_i915_gem_object *obj, struct intel_ring_buffer *to),
+	    TP_ARGS(obj, to),
+
+	    TP_STRUCT__entry(
+			     __field(struct drm_i915_gem_object *, obj)
+			     __field(u32, sync_from)
+			     __field(u32, sync_to)
+			     ),
+
+	    TP_fast_assign(
+			   __entry->obj = obj;
+			   __entry->sync_from = obj->ring->id;
+			   __entry->sync_to = to->id;
+			   ),
+
+	    TP_printk("obj=%p, sync-from=%u, sync-to=%u", __entry->obj, __entry->sync_from, __entry->sync_to)
+);
+
 TRACE_EVENT(i915_vma_bind,
 	    TP_PROTO(struct i915_vma *vma, bool mappable),
 	    TP_ARGS(vma, mappable),
-- 
1.8.4.rc3

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH] drm/i915: Add a tracepoint for using a semaphore
  2013-08-26 12:46 [PATCH] drm/i915: Add a tracepoint for using a semaphore Chris Wilson
@ 2013-08-26 13:20 ` Ville Syrjälä
  2013-08-26 13:30   ` Chris Wilson
  0 siblings, 1 reply; 7+ messages in thread
From: Ville Syrjälä @ 2013-08-26 13:20 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

On Mon, Aug 26, 2013 at 01:46:21PM +0100, Chris Wilson wrote:
> So that we can find the callers who introduce a ring stall. A single
> ring stall is not too unwelcome, the right issue becomes when they start
> to interlock and prevent any concurrent work. That, however, is a little
> tricker to detect with a mere tracepoint!

I was staring at the semaphore code a bit recently, and I was wondering
if it would make sense to do a manual seqno check (against the ring's
current seqno, not just the last sync_seqno) before we decide to
add the semaphore into the ring?

> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
>  drivers/gpu/drm/i915/i915_gem.c   |  2 ++
>  drivers/gpu/drm/i915/i915_trace.h | 19 +++++++++++++++++++
>  2 files changed, 21 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 85537d1..0122278 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2698,6 +2698,8 @@ i915_gem_object_sync(struct drm_i915_gem_object *obj,
>  	if (ret)
>  		return ret;
>  
> +	trace_i915_gem_object_sync(obj, to);
> +
>  	ret = to->sync_to(to, from, seqno);
>  	if (!ret)
>  		/* We use last_read_seqno because sync_to()
> diff --git a/drivers/gpu/drm/i915/i915_trace.h b/drivers/gpu/drm/i915/i915_trace.h
> index feaacbb..728c43b 100644
> --- a/drivers/gpu/drm/i915/i915_trace.h
> +++ b/drivers/gpu/drm/i915/i915_trace.h
> @@ -33,6 +33,25 @@ TRACE_EVENT(i915_gem_object_create,
>  	    TP_printk("obj=%p, size=%u", __entry->obj, __entry->size)
>  );
>  
> +TRACE_EVENT(i915_gem_object_sync,
> +	    TP_PROTO(struct drm_i915_gem_object *obj, struct intel_ring_buffer *to),
> +	    TP_ARGS(obj, to),
> +
> +	    TP_STRUCT__entry(
> +			     __field(struct drm_i915_gem_object *, obj)
> +			     __field(u32, sync_from)
> +			     __field(u32, sync_to)
> +			     ),
> +
> +	    TP_fast_assign(
> +			   __entry->obj = obj;
> +			   __entry->sync_from = obj->ring->id;
> +			   __entry->sync_to = to->id;
> +			   ),
> +
> +	    TP_printk("obj=%p, sync-from=%u, sync-to=%u", __entry->obj, __entry->sync_from, __entry->sync_to)
> +);
> +
>  TRACE_EVENT(i915_vma_bind,
>  	    TP_PROTO(struct i915_vma *vma, bool mappable),
>  	    TP_ARGS(vma, mappable),
> -- 
> 1.8.4.rc3
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] drm/i915: Add a tracepoint for using a semaphore
  2013-08-26 13:20 ` Ville Syrjälä
@ 2013-08-26 13:30   ` Chris Wilson
  0 siblings, 0 replies; 7+ messages in thread
From: Chris Wilson @ 2013-08-26 13:30 UTC (permalink / raw)
  To: Ville Syrjälä; +Cc: intel-gfx

On Mon, Aug 26, 2013 at 04:20:06PM +0300, Ville Syrjälä wrote:
> On Mon, Aug 26, 2013 at 01:46:21PM +0100, Chris Wilson wrote:
> > So that we can find the callers who introduce a ring stall. A single
> > ring stall is not too unwelcome, the right issue becomes when they start
> > to interlock and prevent any concurrent work. That, however, is a little
> > tricker to detect with a mere tracepoint!
> 
> I was staring at the semaphore code a bit recently, and I was wondering
> if it would make sense to do a manual seqno check (against the ring's
> current seqno, not just the last sync_seqno) before we decide to
> add the semaphore into the ring?

If we use the cheap check, yeah. We can also store the cross-sync seqno
as well. Both are going to be unlikely paths though.

Anyway, I'm moving the tracepoint over to the ring rather than the
object for consistency.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [PATCH] drm/i915: Add a tracepoint for using a semaphore
@ 2013-08-26 13:34 Chris Wilson
  0 siblings, 0 replies; 7+ messages in thread
From: Chris Wilson @ 2013-08-26 13:34 UTC (permalink / raw)
  To: intel-gfx

So that we can find the callers who introduce a ring stall. A single
ring stall is not too unwelcome, the right issue becomes when they start
to interlock and prevent any concurrent work. That, however, is a little
tricker to detect with a mere tracepoint!

v2: Rebrand it as a ring event, rather than an object event.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
 drivers/gpu/drm/i915/i915_gem.c   |  2 ++
 drivers/gpu/drm/i915/i915_trace.h | 19 +++++++++++++++++++
 2 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 85537d1..a9a6baa 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2698,6 +2698,8 @@ i915_gem_object_sync(struct drm_i915_gem_object *obj,
 	if (ret)
 		return ret;
 
+	trace_i915_gem_ring_sync_to(from, to);
+
 	ret = to->sync_to(to, from, seqno);
 	if (!ret)
 		/* We use last_read_seqno because sync_to()
diff --git a/drivers/gpu/drm/i915/i915_trace.h b/drivers/gpu/drm/i915/i915_trace.h
index feaacbb..163774a 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -235,6 +235,25 @@ TRACE_EVENT(i915_gem_evict_everything,
 	    TP_printk("dev=%d", __entry->dev)
 );
 
+TRACE_EVENT(i915_gem_ring_sync_to,
+	    TP_PROTO(struct intel_ring_buffer *from, struct intel_ring_buffer *to),
+	    TP_ARGS(from, to),
+
+	    TP_STRUCT__entry(
+			     __field(u32, dev)
+			     __field(u32, sync_from)
+			     __field(u32, sync_to)
+			     ),
+
+	    TP_fast_assign(
+			   __entry->dev = from->dev->primary->index;
+			   __entry->sync_from = from->id;
+			   __entry->sync_to = to->id;
+			   ),
+
+	    TP_printk("dev=%u, sync-from=%u, sync-to=%u", __entry->dev, __entry->sync_from, __entry->sync_to)
+);
+
 TRACE_EVENT(i915_gem_ring_dispatch,
 	    TP_PROTO(struct intel_ring_buffer *ring, u32 flags),
 	    TP_ARGS(ring, flags),
-- 
1.8.4.rc3

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* [PATCH] drm/i915: Add a tracepoint for using a semaphore
  2013-09-25 10:11 [PATCH 09/13] " Daniel Vetter
@ 2013-09-25 10:43 ` Chris Wilson
  2013-09-25 11:29   ` Ville Syrjälä
  0 siblings, 1 reply; 7+ messages in thread
From: Chris Wilson @ 2013-09-25 10:43 UTC (permalink / raw)
  To: intel-gfx

So that we can find the callers who introduce a ring stall. A single
ring stall is not too unwelcome, the right issue becomes when they start
to interlock and prevent any concurrent work. That, however, is a little
tricker to detect with a mere tracepoint!

v2: Rebrand it as a ring event, rather than an object event.
v3: Include the seqno in the tracepoint for posterity or something.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
 drivers/gpu/drm/i915/i915_gem.c   |  1 +
 drivers/gpu/drm/i915/i915_trace.h | 26 ++++++++++++++++++++++++++
 2 files changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 82bc029..fa3b373 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2625,6 +2625,7 @@ i915_gem_object_sync(struct drm_i915_gem_object *obj,
 	if (ret)
 		return ret;
 
+	trace_i915_gem_ring_sync_to(from, to, seqno);
 	ret = to->sync_to(to, from, seqno);
 	if (!ret)
 		/* We use last_read_seqno because sync_to()
diff --git a/drivers/gpu/drm/i915/i915_trace.h b/drivers/gpu/drm/i915/i915_trace.h
index daa6fdf..6e580c9 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -248,6 +248,32 @@ TRACE_EVENT(i915_gem_evict_vm,
 	    TP_printk("dev=%d, vm=%p", __entry->vm->dev->primary->index, __entry->vm)
 );
 
+TRACE_EVENT(i915_gem_ring_sync_to,
+	    TP_PROTO(struct intel_ring_buffer *from,
+		     struct intel_ring_buffer *to,
+		     u32 seqno),
+	    TP_ARGS(from, to, seqno),
+
+	    TP_STRUCT__entry(
+			     __field(u32, dev)
+			     __field(u32, sync_from)
+			     __field(u32, sync_to)
+			     __field(u32, seqno)
+			     ),
+
+	    TP_fast_assign(
+			   __entry->dev = from->dev->primary->index;
+			   __entry->sync_from = from->id;
+			   __entry->sync_to = to->id;
+			   __entry->seqno = seqno;
+			   ),
+
+	    TP_printk("dev=%u, sync-from=%u, sync-to=%u, seqno=%u",
+		      __entry->dev,
+		      __entry->sync_from, __entry->sync_to,
+		      __entry->seqno)
+);
+
 TRACE_EVENT(i915_gem_ring_dispatch,
 	    TP_PROTO(struct intel_ring_buffer *ring, u32 seqno, u32 flags),
 	    TP_ARGS(ring, seqno, flags),
-- 
1.8.4.rc3

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH] drm/i915: Add a tracepoint for using a semaphore
  2013-09-25 10:43 ` [PATCH] " Chris Wilson
@ 2013-09-25 11:29   ` Ville Syrjälä
  2013-09-25 11:31     ` Daniel Vetter
  0 siblings, 1 reply; 7+ messages in thread
From: Ville Syrjälä @ 2013-09-25 11:29 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

On Wed, Sep 25, 2013 at 11:43:28AM +0100, Chris Wilson wrote:
> So that we can find the callers who introduce a ring stall. A single
> ring stall is not too unwelcome, the right issue becomes when they start
> to interlock and prevent any concurrent work. That, however, is a little
> tricker to detect with a mere tracepoint!
> 
> v2: Rebrand it as a ring event, rather than an object event.
> v3: Include the seqno in the tracepoint for posterity or something.
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
>  drivers/gpu/drm/i915/i915_gem.c   |  1 +
>  drivers/gpu/drm/i915/i915_trace.h | 26 ++++++++++++++++++++++++++
>  2 files changed, 27 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 82bc029..fa3b373 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2625,6 +2625,7 @@ i915_gem_object_sync(struct drm_i915_gem_object *obj,
>  	if (ret)
>  		return ret;
>  
> +	trace_i915_gem_ring_sync_to(from, to, seqno);
>  	ret = to->sync_to(to, from, seqno);

Passing the rings in the same order to both might avoid some confusion,
but I don't care enough to withhold my r-b so:
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

>  	if (!ret)
>  		/* We use last_read_seqno because sync_to()
> diff --git a/drivers/gpu/drm/i915/i915_trace.h b/drivers/gpu/drm/i915/i915_trace.h
> index daa6fdf..6e580c9 100644
> --- a/drivers/gpu/drm/i915/i915_trace.h
> +++ b/drivers/gpu/drm/i915/i915_trace.h
> @@ -248,6 +248,32 @@ TRACE_EVENT(i915_gem_evict_vm,
>  	    TP_printk("dev=%d, vm=%p", __entry->vm->dev->primary->index, __entry->vm)
>  );
>  
> +TRACE_EVENT(i915_gem_ring_sync_to,
> +	    TP_PROTO(struct intel_ring_buffer *from,
> +		     struct intel_ring_buffer *to,
> +		     u32 seqno),
> +	    TP_ARGS(from, to, seqno),
> +
> +	    TP_STRUCT__entry(
> +			     __field(u32, dev)
> +			     __field(u32, sync_from)
> +			     __field(u32, sync_to)
> +			     __field(u32, seqno)
> +			     ),
> +
> +	    TP_fast_assign(
> +			   __entry->dev = from->dev->primary->index;
> +			   __entry->sync_from = from->id;
> +			   __entry->sync_to = to->id;
> +			   __entry->seqno = seqno;
> +			   ),
> +
> +	    TP_printk("dev=%u, sync-from=%u, sync-to=%u, seqno=%u",
> +		      __entry->dev,
> +		      __entry->sync_from, __entry->sync_to,
> +		      __entry->seqno)
> +);
> +
>  TRACE_EVENT(i915_gem_ring_dispatch,
>  	    TP_PROTO(struct intel_ring_buffer *ring, u32 seqno, u32 flags),
>  	    TP_ARGS(ring, seqno, flags),
> -- 
> 1.8.4.rc3
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] drm/i915: Add a tracepoint for using a semaphore
  2013-09-25 11:29   ` Ville Syrjälä
@ 2013-09-25 11:31     ` Daniel Vetter
  0 siblings, 0 replies; 7+ messages in thread
From: Daniel Vetter @ 2013-09-25 11:31 UTC (permalink / raw)
  To: Ville Syrjälä; +Cc: intel-gfx

On Wed, Sep 25, 2013 at 02:29:34PM +0300, Ville Syrjälä wrote:
> On Wed, Sep 25, 2013 at 11:43:28AM +0100, Chris Wilson wrote:
> > So that we can find the callers who introduce a ring stall. A single
> > ring stall is not too unwelcome, the right issue becomes when they start
> > to interlock and prevent any concurrent work. That, however, is a little
> > tricker to detect with a mere tracepoint!
> > 
> > v2: Rebrand it as a ring event, rather than an object event.
> > v3: Include the seqno in the tracepoint for posterity or something.
> > 
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > ---
> >  drivers/gpu/drm/i915/i915_gem.c   |  1 +
> >  drivers/gpu/drm/i915/i915_trace.h | 26 ++++++++++++++++++++++++++
> >  2 files changed, 27 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> > index 82bc029..fa3b373 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -2625,6 +2625,7 @@ i915_gem_object_sync(struct drm_i915_gem_object *obj,
> >  	if (ret)
> >  		return ret;
> >  
> > +	trace_i915_gem_ring_sync_to(from, to, seqno);
> >  	ret = to->sync_to(to, from, seqno);
> 
> Passing the rings in the same order to both might avoid some confusion,
> but I don't care enough to withhold my r-b so:
> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

Queued for -next, thanks for the patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2013-09-25 11:30 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-08-26 12:46 [PATCH] drm/i915: Add a tracepoint for using a semaphore Chris Wilson
2013-08-26 13:20 ` Ville Syrjälä
2013-08-26 13:30   ` Chris Wilson
  -- strict thread matches above, loose matches on Subject: below --
2013-08-26 13:34 Chris Wilson
2013-09-25 10:11 [PATCH 09/13] " Daniel Vetter
2013-09-25 10:43 ` [PATCH] " Chris Wilson
2013-09-25 11:29   ` Ville Syrjälä
2013-09-25 11:31     ` Daniel Vetter

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox