From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, Jens Axboe <axboe@kernel.dk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/3] drm/i915: Only spin whilst waiting on the current request
Date: Thu, 19 Nov 2015 10:05:39 +0000 [thread overview]
Message-ID: <564D9EF3.7020506@linux.intel.com> (raw)
In-Reply-To: <1447840568-20167-2-git-send-email-chris@chris-wilson.co.uk>
Hi,
On 18/11/15 09:56, Chris Wilson wrote:
> Limit busywaiting only to the request currently being processed by the
> GPU. If the request is not currently being processed by the GPU, there
> is a very low likelihood of it being completed within the 2 microsecond
> spin timeout and so we will just be wasting CPU cycles.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> drivers/gpu/drm/i915/i915_gem.c | 8 +++++++-
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 8afda459a26e..16095b95d2df 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2190,7 +2190,7 @@ struct drm_i915_gem_request {
> struct intel_engine_cs *ring;
>
> /** GEM sequence number associated with this request. */
> - uint32_t seqno;
> + uint32_t seqno, spin_seqno;
Comment needs splitting out.
And spin_seqno is not the best name, I think previous_ring_seqno would
be better. So it would immediately tell you what it is, and then at the
place which uses it it would also be clearer what is the criteria for
spinning.
> /** Position in the ringbuffer of the start of the request */
> u32 head;
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 414150a0b8d5..af9ffa11ef44 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1193,9 +1193,14 @@ static int __i915_spin_request(struct drm_i915_gem_request *req, int state)
> * takes to sleep on a request, on the order of a microsecond.
> */
>
> - if (i915_gem_request_get_ring(req)->irq_refcount)
> + if (req->ring->irq_refcount)
> return -EBUSY;
>
> + /* Only spin if we know the GPU is processing this request */
> + if (i915_seqno_passed(req->ring->get_seqno(req->ring, false),
> + req->spin_seqno))
> + return -EAGAIN;
> +
> timeout = local_clock_us(&cpu) + 2;
> while (!need_resched()) {
> if (i915_gem_request_completed(req, true))
> @@ -2592,6 +2597,7 @@ void __i915_add_request(struct drm_i915_gem_request *request,
> request->batch_obj = obj;
>
> request->emitted_jiffies = jiffies;
> + request->spin_seqno = ring->last_submitted_seqno;
> ring->last_submitted_seqno = request->seqno;
> list_add_tail(&request->list, &ring->request_list);
Commit message says it will spin only on the request currently being
processed by the GPU but from here it looks like it will spin for any
request _queued up_ before the last?
For example if we have submitted 1, 2, 3 and 4 and GPU is currently
processing 1.
2 has spin_seqno 1.
3 has spin_seqno 2.
4 has spin_seqno 3.
ring->get_seqno is 0.
Wait on 1: seqno_passed(0, 0) = true -> wait
Wait on 2: seqno_passed(0, 1) = false -> spin
Wait on 3: seqno_passed(0, 2) = false -> spin
Wait on 4: seqno_passed(0, 3) = false -> spin
So it looks the opposite.
Or is it too early for me? :)
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-11-19 10:05 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-15 13:32 [PATCH 1/2] drm/i915: Break busywaiting for requests on pending signals Chris Wilson
2015-11-15 13:32 ` [PATCH 2/2] drm/i915: Limit the busy wait on requests to 2us not 10ms! Chris Wilson
2015-11-15 17:48 ` Chris Wilson
2015-11-16 10:24 ` Tvrtko Ursulin
2015-11-16 11:12 ` Chris Wilson
2015-11-16 12:08 ` Tvrtko Ursulin
2015-11-16 12:55 ` Chris Wilson
2015-11-16 13:09 ` Tvrtko Ursulin
2015-11-16 13:30 ` [Intel-gfx] " Ville Syrjälä
2015-11-16 16:48 ` Jens Axboe
2015-11-18 9:56 ` Limit busywaiting Chris Wilson
2015-11-18 9:56 ` [PATCH 1/3] drm/i915: Only spin whilst waiting on the current request Chris Wilson
2015-11-18 17:03 ` Daniel Vetter
2015-11-19 10:05 ` Tvrtko Ursulin [this message]
2015-11-19 10:12 ` Chris Wilson
2015-11-18 9:56 ` [PATCH 2/3] drm/i915: Convert __i915_wait_request to receive flags Chris Wilson
2015-11-18 9:56 ` [PATCH 3/3] drm/i915: Limit request busywaiting Chris Wilson
2015-11-19 15:22 ` Daniel Vetter
2015-11-19 16:29 ` Limit busywaiting Jens Axboe
2015-12-03 22:03 ` [PATCH 2/2] drm/i915: Limit the busy wait on requests to 2us not 10ms! Pavel Machek
2015-11-16 9:54 ` [PATCH 1/2] drm/i915: Break busywaiting for requests on pending signals Tvrtko Ursulin
2015-11-16 11:22 ` Chris Wilson
2015-11-16 11:40 ` Tvrtko Ursulin
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=564D9EF3.7020506@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=axboe@kernel.dk \
--cc=chris@chris-wilson.co.uk \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox