2016-07-20 16:21:08 +08:00
|
|
|
/*
|
|
|
|
* Copyright © 2008-2015 Intel Corporation
|
|
|
|
*
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a
|
|
|
|
* copy of this software and associated documentation files (the "Software"),
|
|
|
|
* to deal in the Software without restriction, including without limitation
|
|
|
|
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
|
|
|
|
* and/or sell copies of the Software, and to permit persons to whom the
|
|
|
|
* Software is furnished to do so, subject to the following conditions:
|
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice (including the next
|
|
|
|
* paragraph) shall be included in all copies or substantial portions of the
|
|
|
|
* Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
|
|
|
|
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
|
|
|
|
* IN THE SOFTWARE.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
drm/i915: Refactor activity tracking for requests
With the introduction of requests, we amplified the number of atomic
refcounted objects we use and update every execbuffer; from none to
several references, and a set of references that need to be changed. We
also introduced interesting side-effects in the order of retiring
requests and objects.
Instead of independently tracking the last request for an object, track
the active objects for each request. The object will reside in the
buffer list of its most recent active request and so we reduce the kref
interchange to a list_move. Now retirements are entirely driven by the
request, dramatically simplifying activity tracking on the object
themselves, and removing the ambiguity between retiring objects and
retiring requests.
Furthermore with the consolidation of managing the activity tracking
centrally, we can look forward to using RCU to enable lockless lookup of
the current active requests for an object. In the future, we will be
able to query the status or wait upon rendering to an object without
even touching the struct_mutex BKL.
All told, less code, simpler and faster, and more extensible.
v2: Add a typedef for the function pointer for convenience later.
v3: Make the noop retirement callback explicit. Allow passing NULL to
the init_request_active() which is expanded to a common noop function.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470293567-10811-16-git-send-email-chris@chris-wilson.co.uk
2016-08-04 14:52:35 +08:00
|
|
|
#include <linux/prefetch.h>
|
2016-10-28 20:58:24 +08:00
|
|
|
#include <linux/dma-fence-array.h>
|
2017-02-01 23:36:40 +08:00
|
|
|
#include <linux/sched.h>
|
|
|
|
#include <linux/sched/clock.h>
|
2017-02-04 06:47:37 +08:00
|
|
|
#include <linux/sched/signal.h>
|
drm/i915: Refactor activity tracking for requests
With the introduction of requests, we amplified the number of atomic
refcounted objects we use and update every execbuffer; from none to
several references, and a set of references that need to be changed. We
also introduced interesting side-effects in the order of retiring
requests and objects.
Instead of independently tracking the last request for an object, track
the active objects for each request. The object will reside in the
buffer list of its most recent active request and so we reduce the kref
interchange to a list_move. Now retirements are entirely driven by the
request, dramatically simplifying activity tracking on the object
themselves, and removing the ambiguity between retiring objects and
retiring requests.
Furthermore with the consolidation of managing the activity tracking
centrally, we can look forward to using RCU to enable lockless lookup of
the current active requests for an object. In the future, we will be
able to query the status or wait upon rendering to an object without
even touching the struct_mutex BKL.
All told, less code, simpler and faster, and more extensible.
v2: Add a typedef for the function pointer for convenience later.
v3: Make the noop retirement callback explicit. Allow passing NULL to
the init_request_active() which is expanded to a common noop function.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470293567-10811-16-git-send-email-chris@chris-wilson.co.uk
2016-08-04 14:52:35 +08:00
|
|
|
|
2016-07-20 16:21:08 +08:00
|
|
|
#include "i915_drv.h"
|
|
|
|
|
2016-10-25 20:00:45 +08:00
|
|
|
static const char *i915_fence_get_driver_name(struct dma_fence *fence)
|
2016-07-20 16:21:11 +08:00
|
|
|
{
|
|
|
|
return "i915";
|
|
|
|
}
|
|
|
|
|
2016-10-25 20:00:45 +08:00
|
|
|
static const char *i915_fence_get_timeline_name(struct dma_fence *fence)
|
2016-07-20 16:21:11 +08:00
|
|
|
{
|
2018-02-21 17:56:36 +08:00
|
|
|
/*
|
|
|
|
* The timeline struct (as part of the ppgtt underneath a context)
|
2017-03-30 19:16:14 +08:00
|
|
|
* may be freed when the request is no longer in use by the GPU.
|
|
|
|
* We could extend the life of a context to beyond that of all
|
|
|
|
* fences, possibly keeping the hw resource around indefinitely,
|
|
|
|
* or we just give them a false name. Since
|
|
|
|
* dma_fence_ops.get_timeline_name is a debug feature, the occasional
|
|
|
|
* lie seems justifiable.
|
|
|
|
*/
|
|
|
|
if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
|
|
|
|
return "signaled";
|
|
|
|
|
2018-05-03 00:38:39 +08:00
|
|
|
return to_request(fence)->timeline->name;
|
2016-07-20 16:21:11 +08:00
|
|
|
}
|
|
|
|
|
2016-10-25 20:00:45 +08:00
|
|
|
static bool i915_fence_signaled(struct dma_fence *fence)
|
2016-07-20 16:21:11 +08:00
|
|
|
{
|
2018-02-21 17:56:36 +08:00
|
|
|
return i915_request_completed(to_request(fence));
|
2016-07-20 16:21:11 +08:00
|
|
|
}
|
|
|
|
|
2016-10-25 20:00:45 +08:00
|
|
|
static bool i915_fence_enable_signaling(struct dma_fence *fence)
|
2016-07-20 16:21:11 +08:00
|
|
|
{
|
2018-03-08 22:07:32 +08:00
|
|
|
return intel_engine_enable_signaling(to_request(fence), true);
|
2016-07-20 16:21:11 +08:00
|
|
|
}
|
|
|
|
|
2016-10-25 20:00:45 +08:00
|
|
|
static signed long i915_fence_wait(struct dma_fence *fence,
|
2016-07-20 16:21:11 +08:00
|
|
|
bool interruptible,
|
2016-10-28 20:58:27 +08:00
|
|
|
signed long timeout)
|
2016-07-20 16:21:11 +08:00
|
|
|
{
|
2018-02-21 17:56:36 +08:00
|
|
|
return i915_request_wait(to_request(fence), interruptible, timeout);
|
2016-07-20 16:21:11 +08:00
|
|
|
}
|
|
|
|
|
2016-10-25 20:00:45 +08:00
|
|
|
static void i915_fence_release(struct dma_fence *fence)
|
2016-07-20 16:21:11 +08:00
|
|
|
{
|
2018-02-21 17:56:36 +08:00
|
|
|
struct i915_request *rq = to_request(fence);
|
2016-07-20 16:21:11 +08:00
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
/*
|
|
|
|
* The request is put onto a RCU freelist (i.e. the address
|
2016-11-25 21:17:18 +08:00
|
|
|
* is immediately reused), mark the fences as being freed now.
|
|
|
|
* Otherwise the debugobjects for the fences are only marked as
|
|
|
|
* freed when the slab cache itself is freed, and so we would get
|
|
|
|
* caught trying to reuse dead objects.
|
|
|
|
*/
|
2018-02-21 17:56:36 +08:00
|
|
|
i915_sw_fence_fini(&rq->submit);
|
2016-11-25 21:17:18 +08:00
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
kmem_cache_free(rq->i915->requests, rq);
|
2016-07-20 16:21:11 +08:00
|
|
|
}
|
|
|
|
|
2016-10-25 20:00:45 +08:00
|
|
|
const struct dma_fence_ops i915_fence_ops = {
|
2016-07-20 16:21:11 +08:00
|
|
|
.get_driver_name = i915_fence_get_driver_name,
|
|
|
|
.get_timeline_name = i915_fence_get_timeline_name,
|
|
|
|
.enable_signaling = i915_fence_enable_signaling,
|
|
|
|
.signaled = i915_fence_signaled,
|
|
|
|
.wait = i915_fence_wait,
|
|
|
|
.release = i915_fence_release,
|
|
|
|
};
|
|
|
|
|
2016-07-20 16:21:08 +08:00
|
|
|
static inline void
|
2018-02-21 17:56:36 +08:00
|
|
|
i915_request_remove_from_client(struct i915_request *request)
|
2016-07-20 16:21:08 +08:00
|
|
|
{
|
2017-03-02 20:25:25 +08:00
|
|
|
struct drm_i915_file_private *file_priv;
|
2016-07-20 16:21:08 +08:00
|
|
|
|
2017-03-02 20:25:25 +08:00
|
|
|
file_priv = request->file_priv;
|
2016-07-20 16:21:08 +08:00
|
|
|
if (!file_priv)
|
|
|
|
return;
|
|
|
|
|
|
|
|
spin_lock(&file_priv->mm.lock);
|
2017-03-02 20:25:25 +08:00
|
|
|
if (request->file_priv) {
|
|
|
|
list_del(&request->client_link);
|
|
|
|
request->file_priv = NULL;
|
|
|
|
}
|
2016-07-20 16:21:08 +08:00
|
|
|
spin_unlock(&file_priv->mm.lock);
|
|
|
|
}
|
|
|
|
|
2017-02-23 15:44:09 +08:00
|
|
|
static int reset_all_global_seqno(struct drm_i915_private *i915, u32 seqno)
|
|
|
|
{
|
|
|
|
struct intel_engine_cs *engine;
|
2018-05-03 00:38:39 +08:00
|
|
|
struct i915_timeline *timeline;
|
2017-02-23 15:44:09 +08:00
|
|
|
enum intel_engine_id id;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
/* Carefully retire all requests without writing to the rings */
|
|
|
|
ret = i915_gem_wait_for_idle(i915,
|
|
|
|
I915_WAIT_INTERRUPTIBLE |
|
2018-07-09 20:20:42 +08:00
|
|
|
I915_WAIT_LOCKED,
|
|
|
|
MAX_SCHEDULE_TIMEOUT);
|
2017-02-23 15:44:09 +08:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2018-03-15 21:14:50 +08:00
|
|
|
GEM_BUG_ON(i915->gt.active_requests);
|
|
|
|
|
2017-02-23 15:44:09 +08:00
|
|
|
/* If the seqno wraps around, we need to clear the breadcrumb rbtree */
|
|
|
|
for_each_engine(engine, i915, id) {
|
2018-03-28 05:01:57 +08:00
|
|
|
GEM_TRACE("%s seqno %d (current %d) -> %d\n",
|
|
|
|
engine->name,
|
2018-05-03 00:38:39 +08:00
|
|
|
engine->timeline.seqno,
|
2018-03-28 05:01:57 +08:00
|
|
|
intel_engine_get_seqno(engine),
|
|
|
|
seqno);
|
2018-03-15 21:14:50 +08:00
|
|
|
|
2018-11-26 17:56:10 +08:00
|
|
|
if (seqno == engine->timeline.seqno)
|
|
|
|
continue;
|
|
|
|
|
2018-10-24 18:49:39 +08:00
|
|
|
kthread_park(engine->breadcrumbs.signaler);
|
|
|
|
|
2018-05-03 00:38:39 +08:00
|
|
|
if (!i915_seqno_passed(seqno, engine->timeline.seqno)) {
|
2018-03-06 21:01:43 +08:00
|
|
|
/* Flush any waiters before we reuse the seqno */
|
|
|
|
intel_engine_disarm_breadcrumbs(engine);
|
2018-05-03 06:03:12 +08:00
|
|
|
intel_engine_init_hangcheck(engine);
|
2018-03-06 21:01:42 +08:00
|
|
|
GEM_BUG_ON(!list_empty(&engine->breadcrumbs.signals));
|
2017-02-23 15:44:09 +08:00
|
|
|
}
|
|
|
|
|
2017-07-21 20:32:26 +08:00
|
|
|
/* Check we are idle before we fiddle with hw state! */
|
|
|
|
GEM_BUG_ON(!intel_engine_is_idle(engine));
|
2018-05-03 00:38:39 +08:00
|
|
|
GEM_BUG_ON(i915_gem_active_isset(&engine->timeline.last_request));
|
2017-07-21 20:32:26 +08:00
|
|
|
|
2017-02-23 15:44:09 +08:00
|
|
|
/* Finally reset hw state */
|
|
|
|
intel_engine_init_global_seqno(engine, seqno);
|
2018-05-03 00:38:39 +08:00
|
|
|
engine->timeline.seqno = seqno;
|
2018-10-24 18:49:39 +08:00
|
|
|
|
|
|
|
kthread_unpark(engine->breadcrumbs.signaler);
|
2017-02-23 15:44:09 +08:00
|
|
|
}
|
|
|
|
|
2018-05-03 00:38:39 +08:00
|
|
|
list_for_each_entry(timeline, &i915->gt.timelines, link)
|
|
|
|
memset(timeline->global_sync, 0, sizeof(timeline->global_sync));
|
|
|
|
|
2018-04-30 21:15:00 +08:00
|
|
|
i915->gt.request_serial = seqno;
|
2018-05-03 00:38:39 +08:00
|
|
|
|
2017-02-23 15:44:09 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int i915_gem_set_global_seqno(struct drm_device *dev, u32 seqno)
|
|
|
|
{
|
2018-02-21 17:56:36 +08:00
|
|
|
struct drm_i915_private *i915 = to_i915(dev);
|
2017-02-23 15:44:09 +08:00
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
lockdep_assert_held(&i915->drm.struct_mutex);
|
2017-02-23 15:44:09 +08:00
|
|
|
|
|
|
|
if (seqno == 0)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
/* HWS page needs to be set less than what we will inject to ring */
|
|
|
|
return reset_all_global_seqno(i915, seqno - 1);
|
2017-02-23 15:44:09 +08:00
|
|
|
}
|
|
|
|
|
2018-04-30 21:15:00 +08:00
|
|
|
static int reserve_gt(struct drm_i915_private *i915)
|
2017-08-17 22:47:19 +08:00
|
|
|
{
|
2017-02-23 15:44:09 +08:00
|
|
|
int ret;
|
|
|
|
|
2018-04-30 21:15:00 +08:00
|
|
|
/*
|
|
|
|
* Reservation is fine until we may need to wrap around
|
|
|
|
*
|
|
|
|
* By incrementing the serial for every request, we know that no
|
|
|
|
* individual engine may exceed that serial (as each is reset to 0
|
|
|
|
* on any wrap). This protects even the most pessimistic of migrations
|
|
|
|
* of every request from all engines onto just one.
|
|
|
|
*/
|
|
|
|
while (unlikely(++i915->gt.request_serial == 0)) {
|
2017-08-17 22:47:19 +08:00
|
|
|
ret = reset_all_global_seqno(i915, 0);
|
|
|
|
if (ret) {
|
2018-04-30 21:15:00 +08:00
|
|
|
i915->gt.request_serial--;
|
2017-08-17 22:47:19 +08:00
|
|
|
return ret;
|
|
|
|
}
|
2017-02-23 15:44:09 +08:00
|
|
|
}
|
|
|
|
|
2017-08-17 22:47:19 +08:00
|
|
|
if (!i915->gt.active_requests++)
|
2018-04-06 23:51:44 +08:00
|
|
|
i915_gem_unpark(i915);
|
2017-08-17 22:47:19 +08:00
|
|
|
|
2017-02-23 15:44:09 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-04-30 21:15:00 +08:00
|
|
|
static void unreserve_gt(struct drm_i915_private *i915)
|
2017-02-23 15:44:08 +08:00
|
|
|
{
|
2018-04-30 21:15:02 +08:00
|
|
|
GEM_BUG_ON(!i915->gt.active_requests);
|
2018-04-06 23:51:44 +08:00
|
|
|
if (!--i915->gt.active_requests)
|
|
|
|
i915_gem_park(i915);
|
2017-02-23 15:44:08 +08:00
|
|
|
}
|
|
|
|
|
drm/i915: Refactor activity tracking for requests
With the introduction of requests, we amplified the number of atomic
refcounted objects we use and update every execbuffer; from none to
several references, and a set of references that need to be changed. We
also introduced interesting side-effects in the order of retiring
requests and objects.
Instead of independently tracking the last request for an object, track
the active objects for each request. The object will reside in the
buffer list of its most recent active request and so we reduce the kref
interchange to a list_move. Now retirements are entirely driven by the
request, dramatically simplifying activity tracking on the object
themselves, and removing the ambiguity between retiring objects and
retiring requests.
Furthermore with the consolidation of managing the activity tracking
centrally, we can look forward to using RCU to enable lockless lookup of
the current active requests for an object. In the future, we will be
able to query the status or wait upon rendering to an object without
even touching the struct_mutex BKL.
All told, less code, simpler and faster, and more extensible.
v2: Add a typedef for the function pointer for convenience later.
v3: Make the noop retirement callback explicit. Allow passing NULL to
the init_request_active() which is expanded to a common noop function.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470293567-10811-16-git-send-email-chris@chris-wilson.co.uk
2016-08-04 14:52:35 +08:00
|
|
|
void i915_gem_retire_noop(struct i915_gem_active *active,
|
2018-02-21 17:56:36 +08:00
|
|
|
struct i915_request *request)
|
drm/i915: Refactor activity tracking for requests
With the introduction of requests, we amplified the number of atomic
refcounted objects we use and update every execbuffer; from none to
several references, and a set of references that need to be changed. We
also introduced interesting side-effects in the order of retiring
requests and objects.
Instead of independently tracking the last request for an object, track
the active objects for each request. The object will reside in the
buffer list of its most recent active request and so we reduce the kref
interchange to a list_move. Now retirements are entirely driven by the
request, dramatically simplifying activity tracking on the object
themselves, and removing the ambiguity between retiring objects and
retiring requests.
Furthermore with the consolidation of managing the activity tracking
centrally, we can look forward to using RCU to enable lockless lookup of
the current active requests for an object. In the future, we will be
able to query the status or wait upon rendering to an object without
even touching the struct_mutex BKL.
All told, less code, simpler and faster, and more extensible.
v2: Add a typedef for the function pointer for convenience later.
v3: Make the noop retirement callback explicit. Allow passing NULL to
the init_request_active() which is expanded to a common noop function.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470293567-10811-16-git-send-email-chris@chris-wilson.co.uk
2016-08-04 14:52:35 +08:00
|
|
|
{
|
|
|
|
/* Space left intentionally blank */
|
|
|
|
}
|
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
static void advance_ring(struct i915_request *request)
|
2017-04-07 01:00:28 +08:00
|
|
|
{
|
2018-04-30 21:15:02 +08:00
|
|
|
struct intel_ring *ring = request->ring;
|
2017-04-07 01:00:28 +08:00
|
|
|
unsigned int tail;
|
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
/*
|
|
|
|
* We know the GPU must have read the request to have
|
2017-04-07 01:00:28 +08:00
|
|
|
* sent us the seqno + interrupt, so use the position
|
|
|
|
* of tail of the request to update the last known position
|
|
|
|
* of the GPU head.
|
|
|
|
*
|
|
|
|
* Note this requires that we are always called in request
|
|
|
|
* completion order.
|
|
|
|
*/
|
2018-04-30 21:15:02 +08:00
|
|
|
GEM_BUG_ON(!list_is_first(&request->ring_link, &ring->request_list));
|
|
|
|
if (list_is_last(&request->ring_link, &ring->request_list)) {
|
2018-02-21 17:56:36 +08:00
|
|
|
/*
|
|
|
|
* We may race here with execlists resubmitting this request
|
2017-04-25 21:00:49 +08:00
|
|
|
* as we retire it. The resubmission will move the ring->tail
|
|
|
|
* forwards (to request->wa_tail). We either read the
|
|
|
|
* current value that was written to hw, or the value that
|
|
|
|
* is just about to be. Either works, if we miss the last two
|
|
|
|
* noops - they are safe to be replayed on a reset.
|
|
|
|
*/
|
2018-05-24 16:11:35 +08:00
|
|
|
GEM_TRACE("marking %s as inactive\n", ring->timeline->name);
|
2018-03-07 21:42:23 +08:00
|
|
|
tail = READ_ONCE(request->tail);
|
2018-04-30 21:15:03 +08:00
|
|
|
list_del(&ring->active_link);
|
2017-04-25 21:00:49 +08:00
|
|
|
} else {
|
2017-04-07 01:00:28 +08:00
|
|
|
tail = request->postfix;
|
2017-04-25 21:00:49 +08:00
|
|
|
}
|
2018-04-30 21:15:02 +08:00
|
|
|
list_del_init(&request->ring_link);
|
2017-04-07 01:00:28 +08:00
|
|
|
|
2018-04-30 21:15:02 +08:00
|
|
|
ring->head = tail;
|
2017-04-07 01:00:28 +08:00
|
|
|
}
|
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
static void free_capture_list(struct i915_request *request)
|
2017-04-15 17:39:02 +08:00
|
|
|
{
|
2018-02-21 17:56:36 +08:00
|
|
|
struct i915_capture_list *capture;
|
2017-04-15 17:39:02 +08:00
|
|
|
|
|
|
|
capture = request->capture_list;
|
|
|
|
while (capture) {
|
2018-02-21 17:56:36 +08:00
|
|
|
struct i915_capture_list *next = capture->next;
|
2017-04-15 17:39:02 +08:00
|
|
|
|
|
|
|
kfree(capture);
|
|
|
|
capture = next;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-04-30 21:15:02 +08:00
|
|
|
static void __retire_engine_request(struct intel_engine_cs *engine,
|
|
|
|
struct i915_request *rq)
|
|
|
|
{
|
|
|
|
GEM_TRACE("%s(%s) fence %llx:%d, global=%d, current %d\n",
|
|
|
|
__func__, engine->name,
|
|
|
|
rq->fence.context, rq->fence.seqno,
|
|
|
|
rq->global_seqno,
|
|
|
|
intel_engine_get_seqno(engine));
|
|
|
|
|
|
|
|
GEM_BUG_ON(!i915_request_completed(rq));
|
|
|
|
|
|
|
|
local_irq_disable();
|
|
|
|
|
2018-05-03 00:38:39 +08:00
|
|
|
spin_lock(&engine->timeline.lock);
|
|
|
|
GEM_BUG_ON(!list_is_first(&rq->link, &engine->timeline.requests));
|
2018-04-30 21:15:02 +08:00
|
|
|
list_del_init(&rq->link);
|
2018-05-03 00:38:39 +08:00
|
|
|
spin_unlock(&engine->timeline.lock);
|
2018-04-30 21:15:02 +08:00
|
|
|
|
|
|
|
spin_lock(&rq->lock);
|
|
|
|
if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &rq->fence.flags))
|
|
|
|
dma_fence_signal_locked(&rq->fence);
|
|
|
|
if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, &rq->fence.flags))
|
|
|
|
intel_engine_cancel_signaling(rq);
|
|
|
|
if (rq->waitboost) {
|
|
|
|
GEM_BUG_ON(!atomic_read(&rq->i915->gt_pm.rps.num_waiters));
|
|
|
|
atomic_dec(&rq->i915->gt_pm.rps.num_waiters);
|
|
|
|
}
|
|
|
|
spin_unlock(&rq->lock);
|
|
|
|
|
|
|
|
local_irq_enable();
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The backing object for the context is done after switching to the
|
|
|
|
* *next* context. Therefore we cannot retire the previous context until
|
|
|
|
* the next context has already started running. However, since we
|
|
|
|
* cannot take the required locks at i915_request_submit() we
|
|
|
|
* defer the unpinning of the active context to now, retirement of
|
|
|
|
* the subsequent request.
|
|
|
|
*/
|
|
|
|
if (engine->last_retired_context)
|
2018-05-18 05:26:32 +08:00
|
|
|
intel_context_unpin(engine->last_retired_context);
|
|
|
|
engine->last_retired_context = rq->hw_context;
|
2018-04-30 21:15:02 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void __retire_engine_upto(struct intel_engine_cs *engine,
|
|
|
|
struct i915_request *rq)
|
|
|
|
{
|
|
|
|
struct i915_request *tmp;
|
|
|
|
|
|
|
|
if (list_empty(&rq->link))
|
|
|
|
return;
|
|
|
|
|
|
|
|
do {
|
2018-05-03 00:38:39 +08:00
|
|
|
tmp = list_first_entry(&engine->timeline.requests,
|
2018-04-30 21:15:02 +08:00
|
|
|
typeof(*tmp), link);
|
|
|
|
|
|
|
|
GEM_BUG_ON(tmp->engine != engine);
|
|
|
|
__retire_engine_request(engine, tmp);
|
|
|
|
} while (tmp != rq);
|
|
|
|
}
|
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
static void i915_request_retire(struct i915_request *request)
|
2016-07-20 16:21:08 +08:00
|
|
|
{
|
drm/i915: Refactor activity tracking for requests
With the introduction of requests, we amplified the number of atomic
refcounted objects we use and update every execbuffer; from none to
several references, and a set of references that need to be changed. We
also introduced interesting side-effects in the order of retiring
requests and objects.
Instead of independently tracking the last request for an object, track
the active objects for each request. The object will reside in the
buffer list of its most recent active request and so we reduce the kref
interchange to a list_move. Now retirements are entirely driven by the
request, dramatically simplifying activity tracking on the object
themselves, and removing the ambiguity between retiring objects and
retiring requests.
Furthermore with the consolidation of managing the activity tracking
centrally, we can look forward to using RCU to enable lockless lookup of
the current active requests for an object. In the future, we will be
able to query the status or wait upon rendering to an object without
even touching the struct_mutex BKL.
All told, less code, simpler and faster, and more extensible.
v2: Add a typedef for the function pointer for convenience later.
v3: Make the noop retirement callback explicit. Allow passing NULL to
the init_request_active() which is expanded to a common noop function.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470293567-10811-16-git-send-email-chris@chris-wilson.co.uk
2016-08-04 14:52:35 +08:00
|
|
|
struct i915_gem_active *active, *next;
|
|
|
|
|
2018-04-06 20:35:14 +08:00
|
|
|
GEM_TRACE("%s fence %llx:%d, global=%d, current %d\n",
|
2018-04-30 21:15:02 +08:00
|
|
|
request->engine->name,
|
2018-03-15 21:14:50 +08:00
|
|
|
request->fence.context, request->fence.seqno,
|
2018-03-28 05:01:57 +08:00
|
|
|
request->global_seqno,
|
2018-04-30 21:15:02 +08:00
|
|
|
intel_engine_get_seqno(request->engine));
|
2018-03-15 21:14:50 +08:00
|
|
|
|
2016-10-28 20:58:32 +08:00
|
|
|
lockdep_assert_held(&request->i915->drm.struct_mutex);
|
2016-11-25 21:17:17 +08:00
|
|
|
GEM_BUG_ON(!i915_sw_fence_signaled(&request->submit));
|
2018-02-21 17:56:36 +08:00
|
|
|
GEM_BUG_ON(!i915_request_completed(request));
|
2016-10-28 20:58:32 +08:00
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
trace_i915_request_retire(request);
|
2016-10-28 20:58:58 +08:00
|
|
|
|
2017-04-07 01:00:28 +08:00
|
|
|
advance_ring(request);
|
2017-04-15 17:39:02 +08:00
|
|
|
free_capture_list(request);
|
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
/*
|
|
|
|
* Walk through the active list, calling retire on each. This allows
|
drm/i915: Refactor activity tracking for requests
With the introduction of requests, we amplified the number of atomic
refcounted objects we use and update every execbuffer; from none to
several references, and a set of references that need to be changed. We
also introduced interesting side-effects in the order of retiring
requests and objects.
Instead of independently tracking the last request for an object, track
the active objects for each request. The object will reside in the
buffer list of its most recent active request and so we reduce the kref
interchange to a list_move. Now retirements are entirely driven by the
request, dramatically simplifying activity tracking on the object
themselves, and removing the ambiguity between retiring objects and
retiring requests.
Furthermore with the consolidation of managing the activity tracking
centrally, we can look forward to using RCU to enable lockless lookup of
the current active requests for an object. In the future, we will be
able to query the status or wait upon rendering to an object without
even touching the struct_mutex BKL.
All told, less code, simpler and faster, and more extensible.
v2: Add a typedef for the function pointer for convenience later.
v3: Make the noop retirement callback explicit. Allow passing NULL to
the init_request_active() which is expanded to a common noop function.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470293567-10811-16-git-send-email-chris@chris-wilson.co.uk
2016-08-04 14:52:35 +08:00
|
|
|
* objects to track their GPU activity and mark themselves as idle
|
|
|
|
* when their *last* active request is completed (updating state
|
|
|
|
* tracking lists for eviction, active references for GEM, etc).
|
|
|
|
*
|
|
|
|
* As the ->retire() may free the node, we decouple it first and
|
|
|
|
* pass along the auxiliary information (to avoid dereferencing
|
|
|
|
* the node after the callback).
|
|
|
|
*/
|
|
|
|
list_for_each_entry_safe(active, next, &request->active_list, link) {
|
2018-02-21 17:56:36 +08:00
|
|
|
/*
|
|
|
|
* In microbenchmarks or focusing upon time inside the kernel,
|
drm/i915: Refactor activity tracking for requests
With the introduction of requests, we amplified the number of atomic
refcounted objects we use and update every execbuffer; from none to
several references, and a set of references that need to be changed. We
also introduced interesting side-effects in the order of retiring
requests and objects.
Instead of independently tracking the last request for an object, track
the active objects for each request. The object will reside in the
buffer list of its most recent active request and so we reduce the kref
interchange to a list_move. Now retirements are entirely driven by the
request, dramatically simplifying activity tracking on the object
themselves, and removing the ambiguity between retiring objects and
retiring requests.
Furthermore with the consolidation of managing the activity tracking
centrally, we can look forward to using RCU to enable lockless lookup of
the current active requests for an object. In the future, we will be
able to query the status or wait upon rendering to an object without
even touching the struct_mutex BKL.
All told, less code, simpler and faster, and more extensible.
v2: Add a typedef for the function pointer for convenience later.
v3: Make the noop retirement callback explicit. Allow passing NULL to
the init_request_active() which is expanded to a common noop function.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470293567-10811-16-git-send-email-chris@chris-wilson.co.uk
2016-08-04 14:52:35 +08:00
|
|
|
* we may spend an inordinate amount of time simply handling
|
|
|
|
* the retirement of requests and processing their callbacks.
|
|
|
|
* Of which, this loop itself is particularly hot due to the
|
|
|
|
* cache misses when jumping around the list of i915_gem_active.
|
|
|
|
* So we try to keep this loop as streamlined as possible and
|
|
|
|
* also prefetch the next i915_gem_active to try and hide
|
|
|
|
* the likely cache miss.
|
|
|
|
*/
|
|
|
|
prefetchw(next);
|
|
|
|
|
|
|
|
INIT_LIST_HEAD(&active->link);
|
drm/i915: Enable lockless lookup of request tracking via RCU
If we enable RCU for the requests (providing a grace period where we can
inspect a "dead" request before it is freed), we can allow callers to
carefully perform lockless lookup of an active request.
However, by enabling deferred freeing of requests, we can potentially
hog a lot of memory when dealing with tens of thousands of requests per
second - with a quick insertion of a synchronize_rcu() inside our
shrinker callback, that issue disappears.
v2: Currently, it is our responsibility to handle reclaim i.e. to avoid
hogging memory with the delayed slab frees. At the moment, we wait for a
grace period in the shrinker, and block for all RCU callbacks on oom.
Suggested alternatives focus on flushing our RCU callback when we have a
certain number of outstanding request frees, and blocking on that flush
after a second high watermark. (So rather than wait for the system to
run out of memory, we stop issuing requests - both are nondeterministic.)
Paul E. McKenney wrote:
Another approach is synchronize_rcu() after some largish number of
requests. The advantage of this approach is that it throttles the
production of callbacks at the source. The corresponding disadvantage
is that it slows things up.
Another approach is to use call_rcu(), but if the previous call_rcu()
is still in flight, block waiting for it. Yet another approach is
the get_state_synchronize_rcu() / cond_synchronize_rcu() pair. The
idea is to do something like this:
cond_synchronize_rcu(cookie);
cookie = get_state_synchronize_rcu();
You would of course do an initial get_state_synchronize_rcu() to
get things going. This would not block unless there was less than
one grace period's worth of time between invocations. But this
assumes a busy system, where there is almost always a grace period
in flight. But you can make that happen as follows:
cond_synchronize_rcu(cookie);
cookie = get_state_synchronize_rcu();
call_rcu(&my_rcu_head, noop_function);
Note that you need additional code to make sure that the old callback
has completed before doing a new one. Setting and clearing a flag
with appropriate memory ordering control suffices (e.g,. smp_load_acquire()
and smp_store_release()).
v3: More comments on compiler and processor order of operations within
the RCU lookup and discover we can use rcu_access_pointer() here instead.
v4: Wrap i915_gem_active_get_rcu() to take the rcu_read_lock itself.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: "Goel, Akash" <akash.goel@intel.com>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1470324762-2545-25-git-send-email-chris@chris-wilson.co.uk
2016-08-04 23:32:41 +08:00
|
|
|
RCU_INIT_POINTER(active->request, NULL);
|
drm/i915: Refactor activity tracking for requests
With the introduction of requests, we amplified the number of atomic
refcounted objects we use and update every execbuffer; from none to
several references, and a set of references that need to be changed. We
also introduced interesting side-effects in the order of retiring
requests and objects.
Instead of independently tracking the last request for an object, track
the active objects for each request. The object will reside in the
buffer list of its most recent active request and so we reduce the kref
interchange to a list_move. Now retirements are entirely driven by the
request, dramatically simplifying activity tracking on the object
themselves, and removing the ambiguity between retiring objects and
retiring requests.
Furthermore with the consolidation of managing the activity tracking
centrally, we can look forward to using RCU to enable lockless lookup of
the current active requests for an object. In the future, we will be
able to query the status or wait upon rendering to an object without
even touching the struct_mutex BKL.
All told, less code, simpler and faster, and more extensible.
v2: Add a typedef for the function pointer for convenience later.
v3: Make the noop retirement callback explicit. Allow passing NULL to
the init_request_active() which is expanded to a common noop function.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470293567-10811-16-git-send-email-chris@chris-wilson.co.uk
2016-08-04 14:52:35 +08:00
|
|
|
|
|
|
|
active->retire(active, request);
|
|
|
|
}
|
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
i915_request_remove_from_client(request);
|
2016-07-20 16:21:08 +08:00
|
|
|
|
2016-11-16 23:20:31 +08:00
|
|
|
/* Retirement decays the ban score as it is a sign of ctx progress */
|
2018-05-18 05:26:30 +08:00
|
|
|
atomic_dec_if_positive(&request->gem_context->ban_score);
|
2018-05-18 05:26:32 +08:00
|
|
|
intel_context_unpin(request->hw_context);
|
2016-11-16 23:20:31 +08:00
|
|
|
|
2018-04-30 21:15:02 +08:00
|
|
|
__retire_engine_upto(request->engine, request);
|
2016-11-15 04:41:02 +08:00
|
|
|
|
2018-04-30 21:15:00 +08:00
|
|
|
unreserve_gt(request->i915);
|
|
|
|
|
2018-04-19 02:40:51 +08:00
|
|
|
i915_sched_node_fini(request->i915, &request->sched);
|
2018-02-21 17:56:36 +08:00
|
|
|
i915_request_put(request);
|
2016-07-20 16:21:08 +08:00
|
|
|
}
|
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
void i915_request_retire_upto(struct i915_request *rq)
|
2016-07-20 16:21:08 +08:00
|
|
|
{
|
2018-04-30 21:15:02 +08:00
|
|
|
struct intel_ring *ring = rq->ring;
|
2018-02-21 17:56:36 +08:00
|
|
|
struct i915_request *tmp;
|
2016-07-20 16:21:08 +08:00
|
|
|
|
2018-04-30 21:15:02 +08:00
|
|
|
GEM_TRACE("%s fence %llx:%d, global=%d, current %d\n",
|
|
|
|
rq->engine->name,
|
|
|
|
rq->fence.context, rq->fence.seqno,
|
|
|
|
rq->global_seqno,
|
|
|
|
intel_engine_get_seqno(rq->engine));
|
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
lockdep_assert_held(&rq->i915->drm.struct_mutex);
|
|
|
|
GEM_BUG_ON(!i915_request_completed(rq));
|
2016-11-25 21:17:15 +08:00
|
|
|
|
2018-04-30 21:15:02 +08:00
|
|
|
if (list_empty(&rq->ring_link))
|
2016-10-28 20:58:27 +08:00
|
|
|
return;
|
2016-07-20 16:21:08 +08:00
|
|
|
|
|
|
|
do {
|
2018-04-30 21:15:02 +08:00
|
|
|
tmp = list_first_entry(&ring->request_list,
|
|
|
|
typeof(*tmp), ring_link);
|
2016-07-20 16:21:08 +08:00
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
i915_request_retire(tmp);
|
|
|
|
} while (tmp != rq);
|
2016-07-20 16:21:08 +08:00
|
|
|
}
|
|
|
|
|
2018-05-03 00:38:39 +08:00
|
|
|
static u32 timeline_get_seqno(struct i915_timeline *tl)
|
2016-07-20 16:21:08 +08:00
|
|
|
{
|
2017-02-23 15:44:08 +08:00
|
|
|
return ++tl->seqno;
|
2016-10-28 20:58:56 +08:00
|
|
|
}
|
|
|
|
|
2018-03-22 21:10:34 +08:00
|
|
|
static void move_to_timeline(struct i915_request *request,
|
2018-05-03 00:38:39 +08:00
|
|
|
struct i915_timeline *timeline)
|
2018-03-22 21:10:34 +08:00
|
|
|
{
|
2018-05-03 00:38:39 +08:00
|
|
|
GEM_BUG_ON(request->timeline == &request->engine->timeline);
|
|
|
|
lockdep_assert_held(&request->engine->timeline.lock);
|
2018-03-22 21:10:34 +08:00
|
|
|
|
2018-07-07 05:07:10 +08:00
|
|
|
spin_lock(&request->timeline->lock);
|
2018-03-22 21:10:34 +08:00
|
|
|
list_move_tail(&request->link, &timeline->requests);
|
|
|
|
spin_unlock(&request->timeline->lock);
|
|
|
|
}
|
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
void __i915_request_submit(struct i915_request *request)
|
2016-09-09 21:11:54 +08:00
|
|
|
{
|
2016-10-28 20:58:46 +08:00
|
|
|
struct intel_engine_cs *engine = request->engine;
|
2016-10-28 20:58:57 +08:00
|
|
|
u32 seqno;
|
2016-09-09 21:11:54 +08:00
|
|
|
|
2018-04-06 20:35:14 +08:00
|
|
|
GEM_TRACE("%s fence %llx:%d -> global=%d, current %d\n",
|
2018-03-28 05:01:57 +08:00
|
|
|
engine->name,
|
2018-03-15 21:14:50 +08:00
|
|
|
request->fence.context, request->fence.seqno,
|
2018-05-03 00:38:39 +08:00
|
|
|
engine->timeline.seqno + 1,
|
2018-03-28 05:01:57 +08:00
|
|
|
intel_engine_get_seqno(engine));
|
2018-03-15 21:14:50 +08:00
|
|
|
|
2017-03-02 19:51:30 +08:00
|
|
|
GEM_BUG_ON(!irqs_disabled());
|
2018-05-03 00:38:39 +08:00
|
|
|
lockdep_assert_held(&engine->timeline.lock);
|
2017-03-02 19:51:30 +08:00
|
|
|
|
2017-12-22 22:19:59 +08:00
|
|
|
GEM_BUG_ON(request->global_seqno);
|
2016-09-09 21:11:54 +08:00
|
|
|
|
2018-05-03 00:38:39 +08:00
|
|
|
seqno = timeline_get_seqno(&engine->timeline);
|
2016-10-28 20:58:57 +08:00
|
|
|
GEM_BUG_ON(!seqno);
|
2018-08-06 19:26:05 +08:00
|
|
|
GEM_BUG_ON(intel_engine_signaled(engine, seqno));
|
2016-10-28 20:58:57 +08:00
|
|
|
|
|
|
|
/* We may be recursing from the signal callback of another i915 fence */
|
|
|
|
spin_lock_nested(&request->lock, SINGLE_DEPTH_NESTING);
|
|
|
|
request->global_seqno = seqno;
|
|
|
|
if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, &request->fence.flags))
|
2017-04-26 16:06:59 +08:00
|
|
|
intel_engine_enable_signaling(request, false);
|
2016-10-28 20:58:57 +08:00
|
|
|
spin_unlock(&request->lock);
|
|
|
|
|
2016-10-28 20:58:52 +08:00
|
|
|
engine->emit_breadcrumb(request,
|
|
|
|
request->ring->vaddr + request->postfix);
|
2016-09-09 21:11:54 +08:00
|
|
|
|
2018-03-22 21:10:34 +08:00
|
|
|
/* Transfer from per-context onto the global per-engine timeline */
|
2018-05-03 00:38:39 +08:00
|
|
|
move_to_timeline(request, &engine->timeline);
|
2016-10-28 20:58:58 +08:00
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
trace_i915_request_execute(request);
|
2018-02-20 18:47:42 +08:00
|
|
|
|
2017-02-23 15:44:13 +08:00
|
|
|
wake_up_all(&request->execute);
|
2016-11-15 04:40:59 +08:00
|
|
|
}
|
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
void i915_request_submit(struct i915_request *request)
|
2016-11-15 04:40:59 +08:00
|
|
|
{
|
|
|
|
struct intel_engine_cs *engine = request->engine;
|
|
|
|
unsigned long flags;
|
2016-11-15 04:40:58 +08:00
|
|
|
|
2016-11-15 04:40:59 +08:00
|
|
|
/* Will be called from irq-context when using foreign fences. */
|
2018-05-03 00:38:39 +08:00
|
|
|
spin_lock_irqsave(&engine->timeline.lock, flags);
|
2016-11-15 04:40:59 +08:00
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
__i915_request_submit(request);
|
2016-11-15 04:40:59 +08:00
|
|
|
|
2018-05-03 00:38:39 +08:00
|
|
|
spin_unlock_irqrestore(&engine->timeline.lock, flags);
|
2016-11-15 04:40:59 +08:00
|
|
|
}
|
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
void __i915_request_unsubmit(struct i915_request *request)
|
2016-11-15 04:40:59 +08:00
|
|
|
{
|
2017-02-23 15:44:17 +08:00
|
|
|
struct intel_engine_cs *engine = request->engine;
|
2016-11-15 04:40:59 +08:00
|
|
|
|
2018-04-06 20:35:14 +08:00
|
|
|
GEM_TRACE("%s fence %llx:%d <- global=%d, current %d\n",
|
2018-03-28 05:01:57 +08:00
|
|
|
engine->name,
|
2018-03-15 21:14:50 +08:00
|
|
|
request->fence.context, request->fence.seqno,
|
2018-03-28 05:01:57 +08:00
|
|
|
request->global_seqno,
|
|
|
|
intel_engine_get_seqno(engine));
|
2018-03-15 21:14:50 +08:00
|
|
|
|
2017-03-02 19:51:30 +08:00
|
|
|
GEM_BUG_ON(!irqs_disabled());
|
2018-05-03 00:38:39 +08:00
|
|
|
lockdep_assert_held(&engine->timeline.lock);
|
2016-11-25 21:17:17 +08:00
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
/*
|
|
|
|
* Only unwind in reverse order, required so that the per-context list
|
2017-02-23 15:44:17 +08:00
|
|
|
* is kept in seqno/ring order.
|
|
|
|
*/
|
2017-12-22 22:19:59 +08:00
|
|
|
GEM_BUG_ON(!request->global_seqno);
|
2018-05-03 00:38:39 +08:00
|
|
|
GEM_BUG_ON(request->global_seqno != engine->timeline.seqno);
|
2018-08-06 19:26:05 +08:00
|
|
|
GEM_BUG_ON(intel_engine_has_completed(engine, request->global_seqno));
|
2018-05-03 00:38:39 +08:00
|
|
|
engine->timeline.seqno--;
|
2016-10-28 20:58:58 +08:00
|
|
|
|
2017-02-23 15:44:17 +08:00
|
|
|
/* We may be recursing from the signal callback of another i915 fence */
|
|
|
|
spin_lock_nested(&request->lock, SINGLE_DEPTH_NESTING);
|
|
|
|
request->global_seqno = 0;
|
|
|
|
if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, &request->fence.flags))
|
|
|
|
intel_engine_cancel_signaling(request);
|
|
|
|
spin_unlock(&request->lock);
|
|
|
|
|
|
|
|
/* Transfer back from the global per-engine timeline to per-context */
|
2018-03-22 21:10:34 +08:00
|
|
|
move_to_timeline(request, request->timeline);
|
2017-02-23 15:44:17 +08:00
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
/*
|
|
|
|
* We don't need to wake_up any waiters on request->execute, they
|
2017-02-23 15:44:17 +08:00
|
|
|
* will get woken by any other event or us re-adding this request
|
2018-02-21 17:56:36 +08:00
|
|
|
* to the engine timeline (__i915_request_submit()). The waiters
|
2017-02-23 15:44:17 +08:00
|
|
|
* should be quite adapt at finding that the request now has a new
|
|
|
|
* global_seqno to the one they went to sleep on.
|
|
|
|
*/
|
|
|
|
}
|
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
void i915_request_unsubmit(struct i915_request *request)
|
2017-02-23 15:44:17 +08:00
|
|
|
{
|
|
|
|
struct intel_engine_cs *engine = request->engine;
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
/* Will be called from irq-context when using foreign fences. */
|
2018-05-03 00:38:39 +08:00
|
|
|
spin_lock_irqsave(&engine->timeline.lock, flags);
|
2017-02-23 15:44:17 +08:00
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
__i915_request_unsubmit(request);
|
2017-02-23 15:44:17 +08:00
|
|
|
|
2018-05-03 00:38:39 +08:00
|
|
|
spin_unlock_irqrestore(&engine->timeline.lock, flags);
|
2016-09-09 21:11:54 +08:00
|
|
|
}
|
|
|
|
|
2016-11-15 04:40:58 +08:00
|
|
|
static int __i915_sw_fence_call
|
2016-11-15 04:40:59 +08:00
|
|
|
submit_notify(struct i915_sw_fence *fence, enum i915_sw_fence_notify state)
|
2016-11-15 04:40:58 +08:00
|
|
|
{
|
2018-02-21 17:56:36 +08:00
|
|
|
struct i915_request *request =
|
2016-11-25 21:17:17 +08:00
|
|
|
container_of(fence, typeof(*request), submit);
|
|
|
|
|
|
|
|
switch (state) {
|
|
|
|
case FENCE_COMPLETE:
|
2018-02-21 17:56:36 +08:00
|
|
|
trace_i915_request_submit(request);
|
drm/i915: Use rcu instead of stop_machine in set_wedged
stop_machine is not really a locking primitive we should use, except
when the hw folks tell us the hw is broken and that's the only way to
work around it.
This patch tries to address the locking abuse of stop_machine() from
commit 20e4933c478a1ca694b38fa4ac44d99e659941f5
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Nov 22 14:41:21 2016 +0000
drm/i915: Stop the machine as we install the wedged submit_request handler
Chris said parts of the reasons for going with stop_machine() was that
it's no overhead for the fast-path. But these callbacks use irqsave
spinlocks and do a bunch of MMIO, and rcu_read_lock is _real_ fast.
To stay as close as possible to the stop_machine semantics we first
update all the submit function pointers to the nop handler, then call
synchronize_rcu() to make sure no new requests can be submitted. This
should give us exactly the huge barrier we want.
I pondered whether we should annotate engine->submit_request as __rcu
and use rcu_assign_pointer and rcu_dereference on it. But the reason
behind those is to make sure the compiler/cpu barriers are there for
when you have an actual data structure you point at, to make sure all
the writes are seen correctly on the read side. But we just have a
function pointer, and .text isn't changed, so no need for these
barriers and hence no need for annotations.
Unfortunately there's a complication with the call to
intel_engine_init_global_seqno:
- Without stop_machine we must hold the corresponding spinlock.
- Without stop_machine we must ensure that all requests are marked as
having failed with dma_fence_set_error() before we call it. That
means we need to split the nop request submission into two phases,
both synchronized with rcu:
1. Only stop submitting the requests to hw and mark them as failed.
2. After all pending requests in the scheduler/ring are suitably
marked up as failed and we can force complete them all, also force
complete by calling intel_engine_init_global_seqno().
This should fix the followwing lockdep splat:
======================================================
WARNING: possible circular locking dependency detected
4.14.0-rc3-CI-CI_DRM_3179+ #1 Tainted: G U
------------------------------------------------------
kworker/3:4/562 is trying to acquire lock:
(cpu_hotplug_lock.rw_sem){++++}, at: [<ffffffff8113d4bc>] stop_machine+0x1c/0x40
but task is already holding lock:
(&dev->struct_mutex){+.+.}, at: [<ffffffffa0136588>] i915_reset_device+0x1e8/0x260 [i915]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #6 (&dev->struct_mutex){+.+.}:
__lock_acquire+0x1420/0x15e0
lock_acquire+0xb0/0x200
__mutex_lock+0x86/0x9b0
mutex_lock_interruptible_nested+0x1b/0x20
i915_mutex_lock_interruptible+0x51/0x130 [i915]
i915_gem_fault+0x209/0x650 [i915]
__do_fault+0x1e/0x80
__handle_mm_fault+0xa08/0xed0
handle_mm_fault+0x156/0x300
__do_page_fault+0x2c5/0x570
do_page_fault+0x28/0x250
page_fault+0x22/0x30
-> #5 (&mm->mmap_sem){++++}:
__lock_acquire+0x1420/0x15e0
lock_acquire+0xb0/0x200
__might_fault+0x68/0x90
_copy_to_user+0x23/0x70
filldir+0xa5/0x120
dcache_readdir+0xf9/0x170
iterate_dir+0x69/0x1a0
SyS_getdents+0xa5/0x140
entry_SYSCALL_64_fastpath+0x1c/0xb1
-> #4 (&sb->s_type->i_mutex_key#5){++++}:
down_write+0x3b/0x70
handle_create+0xcb/0x1e0
devtmpfsd+0x139/0x180
kthread+0x152/0x190
ret_from_fork+0x27/0x40
-> #3 ((complete)&req.done){+.+.}:
__lock_acquire+0x1420/0x15e0
lock_acquire+0xb0/0x200
wait_for_common+0x58/0x210
wait_for_completion+0x1d/0x20
devtmpfs_create_node+0x13d/0x160
device_add+0x5eb/0x620
device_create_groups_vargs+0xe0/0xf0
device_create+0x3a/0x40
msr_device_create+0x2b/0x40
cpuhp_invoke_callback+0xc9/0xbf0
cpuhp_thread_fun+0x17b/0x240
smpboot_thread_fn+0x18a/0x280
kthread+0x152/0x190
ret_from_fork+0x27/0x40
-> #2 (cpuhp_state-up){+.+.}:
__lock_acquire+0x1420/0x15e0
lock_acquire+0xb0/0x200
cpuhp_issue_call+0x133/0x1c0
__cpuhp_setup_state_cpuslocked+0x139/0x2a0
__cpuhp_setup_state+0x46/0x60
page_writeback_init+0x43/0x67
pagecache_init+0x3d/0x42
start_kernel+0x3a8/0x3fc
x86_64_start_reservations+0x2a/0x2c
x86_64_start_kernel+0x6d/0x70
verify_cpu+0x0/0xfb
-> #1 (cpuhp_state_mutex){+.+.}:
__lock_acquire+0x1420/0x15e0
lock_acquire+0xb0/0x200
__mutex_lock+0x86/0x9b0
mutex_lock_nested+0x1b/0x20
__cpuhp_setup_state_cpuslocked+0x53/0x2a0
__cpuhp_setup_state+0x46/0x60
page_alloc_init+0x28/0x30
start_kernel+0x145/0x3fc
x86_64_start_reservations+0x2a/0x2c
x86_64_start_kernel+0x6d/0x70
verify_cpu+0x0/0xfb
-> #0 (cpu_hotplug_lock.rw_sem){++++}:
check_prev_add+0x430/0x840
__lock_acquire+0x1420/0x15e0
lock_acquire+0xb0/0x200
cpus_read_lock+0x3d/0xb0
stop_machine+0x1c/0x40
i915_gem_set_wedged+0x1a/0x20 [i915]
i915_reset+0xb9/0x230 [i915]
i915_reset_device+0x1f6/0x260 [i915]
i915_handle_error+0x2d8/0x430 [i915]
hangcheck_declare_hang+0xd3/0xf0 [i915]
i915_hangcheck_elapsed+0x262/0x2d0 [i915]
process_one_work+0x233/0x660
worker_thread+0x4e/0x3b0
kthread+0x152/0x190
ret_from_fork+0x27/0x40
other info that might help us debug this:
Chain exists of:
cpu_hotplug_lock.rw_sem --> &mm->mmap_sem --> &dev->struct_mutex
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&dev->struct_mutex);
lock(&mm->mmap_sem);
lock(&dev->struct_mutex);
lock(cpu_hotplug_lock.rw_sem);
*** DEADLOCK ***
3 locks held by kworker/3:4/562:
#0: ("events_long"){+.+.}, at: [<ffffffff8109c64a>] process_one_work+0x1aa/0x660
#1: ((&(&i915->gpu_error.hangcheck_work)->work)){+.+.}, at: [<ffffffff8109c64a>] process_one_work+0x1aa/0x660
#2: (&dev->struct_mutex){+.+.}, at: [<ffffffffa0136588>] i915_reset_device+0x1e8/0x260 [i915]
stack backtrace:
CPU: 3 PID: 562 Comm: kworker/3:4 Tainted: G U 4.14.0-rc3-CI-CI_DRM_3179+ #1
Hardware name: /NUC7i5BNB, BIOS BNKBL357.86A.0048.2017.0704.1415 07/04/2017
Workqueue: events_long i915_hangcheck_elapsed [i915]
Call Trace:
dump_stack+0x68/0x9f
print_circular_bug+0x235/0x3c0
? lockdep_init_map_crosslock+0x20/0x20
check_prev_add+0x430/0x840
? irq_work_queue+0x86/0xe0
? wake_up_klogd+0x53/0x70
__lock_acquire+0x1420/0x15e0
? __lock_acquire+0x1420/0x15e0
? lockdep_init_map_crosslock+0x20/0x20
lock_acquire+0xb0/0x200
? stop_machine+0x1c/0x40
? i915_gem_object_truncate+0x50/0x50 [i915]
cpus_read_lock+0x3d/0xb0
? stop_machine+0x1c/0x40
stop_machine+0x1c/0x40
i915_gem_set_wedged+0x1a/0x20 [i915]
i915_reset+0xb9/0x230 [i915]
i915_reset_device+0x1f6/0x260 [i915]
? gen8_gt_irq_ack+0x170/0x170 [i915]
? work_on_cpu_safe+0x60/0x60
i915_handle_error+0x2d8/0x430 [i915]
? vsnprintf+0xd1/0x4b0
? scnprintf+0x3a/0x70
hangcheck_declare_hang+0xd3/0xf0 [i915]
? intel_runtime_pm_put+0x56/0xa0 [i915]
i915_hangcheck_elapsed+0x262/0x2d0 [i915]
process_one_work+0x233/0x660
worker_thread+0x4e/0x3b0
kthread+0x152/0x190
? process_one_work+0x660/0x660
? kthread_create_on_node+0x40/0x40
ret_from_fork+0x27/0x40
Setting dangerous option reset - tainting kernel
i915 0000:00:02.0: Resetting chip after gpu hang
Setting dangerous option reset - tainting kernel
i915 0000:00:02.0: Resetting chip after gpu hang
v2: Have 1 global synchronize_rcu() barrier across all engines, and
improve commit message.
v3: We need to protect the seqno update with the timeline spinlock (in
set_wedged) to avoid racing with other updates of the seqno, like we
already do in nop_submit_request (Chris).
v4: Use two-phase sequence to plug the race Chris spotted where we can
complete requests before they're marked up with -EIO.
v5: Review from Chris:
- simplify nop_submit_request.
- Add comment to rcu_read_lock section.
- Align comments with the new style.
v6: Remove unused variable to appease CI.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102886
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103096
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Marta Lofstedt <marta.lofstedt@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171011091019.1425-1-daniel.vetter@ffwll.ch
2017-10-11 17:10:19 +08:00
|
|
|
/*
|
2018-02-21 17:56:36 +08:00
|
|
|
* We need to serialize use of the submit_request() callback
|
|
|
|
* with its hotplugging performed during an emergency
|
|
|
|
* i915_gem_set_wedged(). We use the RCU mechanism to mark the
|
|
|
|
* critical section in order to force i915_gem_set_wedged() to
|
|
|
|
* wait until the submit_request() is completed before
|
|
|
|
* proceeding.
|
drm/i915: Use rcu instead of stop_machine in set_wedged
stop_machine is not really a locking primitive we should use, except
when the hw folks tell us the hw is broken and that's the only way to
work around it.
This patch tries to address the locking abuse of stop_machine() from
commit 20e4933c478a1ca694b38fa4ac44d99e659941f5
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Nov 22 14:41:21 2016 +0000
drm/i915: Stop the machine as we install the wedged submit_request handler
Chris said parts of the reasons for going with stop_machine() was that
it's no overhead for the fast-path. But these callbacks use irqsave
spinlocks and do a bunch of MMIO, and rcu_read_lock is _real_ fast.
To stay as close as possible to the stop_machine semantics we first
update all the submit function pointers to the nop handler, then call
synchronize_rcu() to make sure no new requests can be submitted. This
should give us exactly the huge barrier we want.
I pondered whether we should annotate engine->submit_request as __rcu
and use rcu_assign_pointer and rcu_dereference on it. But the reason
behind those is to make sure the compiler/cpu barriers are there for
when you have an actual data structure you point at, to make sure all
the writes are seen correctly on the read side. But we just have a
function pointer, and .text isn't changed, so no need for these
barriers and hence no need for annotations.
Unfortunately there's a complication with the call to
intel_engine_init_global_seqno:
- Without stop_machine we must hold the corresponding spinlock.
- Without stop_machine we must ensure that all requests are marked as
having failed with dma_fence_set_error() before we call it. That
means we need to split the nop request submission into two phases,
both synchronized with rcu:
1. Only stop submitting the requests to hw and mark them as failed.
2. After all pending requests in the scheduler/ring are suitably
marked up as failed and we can force complete them all, also force
complete by calling intel_engine_init_global_seqno().
This should fix the followwing lockdep splat:
======================================================
WARNING: possible circular locking dependency detected
4.14.0-rc3-CI-CI_DRM_3179+ #1 Tainted: G U
------------------------------------------------------
kworker/3:4/562 is trying to acquire lock:
(cpu_hotplug_lock.rw_sem){++++}, at: [<ffffffff8113d4bc>] stop_machine+0x1c/0x40
but task is already holding lock:
(&dev->struct_mutex){+.+.}, at: [<ffffffffa0136588>] i915_reset_device+0x1e8/0x260 [i915]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #6 (&dev->struct_mutex){+.+.}:
__lock_acquire+0x1420/0x15e0
lock_acquire+0xb0/0x200
__mutex_lock+0x86/0x9b0
mutex_lock_interruptible_nested+0x1b/0x20
i915_mutex_lock_interruptible+0x51/0x130 [i915]
i915_gem_fault+0x209/0x650 [i915]
__do_fault+0x1e/0x80
__handle_mm_fault+0xa08/0xed0
handle_mm_fault+0x156/0x300
__do_page_fault+0x2c5/0x570
do_page_fault+0x28/0x250
page_fault+0x22/0x30
-> #5 (&mm->mmap_sem){++++}:
__lock_acquire+0x1420/0x15e0
lock_acquire+0xb0/0x200
__might_fault+0x68/0x90
_copy_to_user+0x23/0x70
filldir+0xa5/0x120
dcache_readdir+0xf9/0x170
iterate_dir+0x69/0x1a0
SyS_getdents+0xa5/0x140
entry_SYSCALL_64_fastpath+0x1c/0xb1
-> #4 (&sb->s_type->i_mutex_key#5){++++}:
down_write+0x3b/0x70
handle_create+0xcb/0x1e0
devtmpfsd+0x139/0x180
kthread+0x152/0x190
ret_from_fork+0x27/0x40
-> #3 ((complete)&req.done){+.+.}:
__lock_acquire+0x1420/0x15e0
lock_acquire+0xb0/0x200
wait_for_common+0x58/0x210
wait_for_completion+0x1d/0x20
devtmpfs_create_node+0x13d/0x160
device_add+0x5eb/0x620
device_create_groups_vargs+0xe0/0xf0
device_create+0x3a/0x40
msr_device_create+0x2b/0x40
cpuhp_invoke_callback+0xc9/0xbf0
cpuhp_thread_fun+0x17b/0x240
smpboot_thread_fn+0x18a/0x280
kthread+0x152/0x190
ret_from_fork+0x27/0x40
-> #2 (cpuhp_state-up){+.+.}:
__lock_acquire+0x1420/0x15e0
lock_acquire+0xb0/0x200
cpuhp_issue_call+0x133/0x1c0
__cpuhp_setup_state_cpuslocked+0x139/0x2a0
__cpuhp_setup_state+0x46/0x60
page_writeback_init+0x43/0x67
pagecache_init+0x3d/0x42
start_kernel+0x3a8/0x3fc
x86_64_start_reservations+0x2a/0x2c
x86_64_start_kernel+0x6d/0x70
verify_cpu+0x0/0xfb
-> #1 (cpuhp_state_mutex){+.+.}:
__lock_acquire+0x1420/0x15e0
lock_acquire+0xb0/0x200
__mutex_lock+0x86/0x9b0
mutex_lock_nested+0x1b/0x20
__cpuhp_setup_state_cpuslocked+0x53/0x2a0
__cpuhp_setup_state+0x46/0x60
page_alloc_init+0x28/0x30
start_kernel+0x145/0x3fc
x86_64_start_reservations+0x2a/0x2c
x86_64_start_kernel+0x6d/0x70
verify_cpu+0x0/0xfb
-> #0 (cpu_hotplug_lock.rw_sem){++++}:
check_prev_add+0x430/0x840
__lock_acquire+0x1420/0x15e0
lock_acquire+0xb0/0x200
cpus_read_lock+0x3d/0xb0
stop_machine+0x1c/0x40
i915_gem_set_wedged+0x1a/0x20 [i915]
i915_reset+0xb9/0x230 [i915]
i915_reset_device+0x1f6/0x260 [i915]
i915_handle_error+0x2d8/0x430 [i915]
hangcheck_declare_hang+0xd3/0xf0 [i915]
i915_hangcheck_elapsed+0x262/0x2d0 [i915]
process_one_work+0x233/0x660
worker_thread+0x4e/0x3b0
kthread+0x152/0x190
ret_from_fork+0x27/0x40
other info that might help us debug this:
Chain exists of:
cpu_hotplug_lock.rw_sem --> &mm->mmap_sem --> &dev->struct_mutex
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&dev->struct_mutex);
lock(&mm->mmap_sem);
lock(&dev->struct_mutex);
lock(cpu_hotplug_lock.rw_sem);
*** DEADLOCK ***
3 locks held by kworker/3:4/562:
#0: ("events_long"){+.+.}, at: [<ffffffff8109c64a>] process_one_work+0x1aa/0x660
#1: ((&(&i915->gpu_error.hangcheck_work)->work)){+.+.}, at: [<ffffffff8109c64a>] process_one_work+0x1aa/0x660
#2: (&dev->struct_mutex){+.+.}, at: [<ffffffffa0136588>] i915_reset_device+0x1e8/0x260 [i915]
stack backtrace:
CPU: 3 PID: 562 Comm: kworker/3:4 Tainted: G U 4.14.0-rc3-CI-CI_DRM_3179+ #1
Hardware name: /NUC7i5BNB, BIOS BNKBL357.86A.0048.2017.0704.1415 07/04/2017
Workqueue: events_long i915_hangcheck_elapsed [i915]
Call Trace:
dump_stack+0x68/0x9f
print_circular_bug+0x235/0x3c0
? lockdep_init_map_crosslock+0x20/0x20
check_prev_add+0x430/0x840
? irq_work_queue+0x86/0xe0
? wake_up_klogd+0x53/0x70
__lock_acquire+0x1420/0x15e0
? __lock_acquire+0x1420/0x15e0
? lockdep_init_map_crosslock+0x20/0x20
lock_acquire+0xb0/0x200
? stop_machine+0x1c/0x40
? i915_gem_object_truncate+0x50/0x50 [i915]
cpus_read_lock+0x3d/0xb0
? stop_machine+0x1c/0x40
stop_machine+0x1c/0x40
i915_gem_set_wedged+0x1a/0x20 [i915]
i915_reset+0xb9/0x230 [i915]
i915_reset_device+0x1f6/0x260 [i915]
? gen8_gt_irq_ack+0x170/0x170 [i915]
? work_on_cpu_safe+0x60/0x60
i915_handle_error+0x2d8/0x430 [i915]
? vsnprintf+0xd1/0x4b0
? scnprintf+0x3a/0x70
hangcheck_declare_hang+0xd3/0xf0 [i915]
? intel_runtime_pm_put+0x56/0xa0 [i915]
i915_hangcheck_elapsed+0x262/0x2d0 [i915]
process_one_work+0x233/0x660
worker_thread+0x4e/0x3b0
kthread+0x152/0x190
? process_one_work+0x660/0x660
? kthread_create_on_node+0x40/0x40
ret_from_fork+0x27/0x40
Setting dangerous option reset - tainting kernel
i915 0000:00:02.0: Resetting chip after gpu hang
Setting dangerous option reset - tainting kernel
i915 0000:00:02.0: Resetting chip after gpu hang
v2: Have 1 global synchronize_rcu() barrier across all engines, and
improve commit message.
v3: We need to protect the seqno update with the timeline spinlock (in
set_wedged) to avoid racing with other updates of the seqno, like we
already do in nop_submit_request (Chris).
v4: Use two-phase sequence to plug the race Chris spotted where we can
complete requests before they're marked up with -EIO.
v5: Review from Chris:
- simplify nop_submit_request.
- Add comment to rcu_read_lock section.
- Align comments with the new style.
v6: Remove unused variable to appease CI.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102886
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103096
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Marta Lofstedt <marta.lofstedt@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171011091019.1425-1-daniel.vetter@ffwll.ch
2017-10-11 17:10:19 +08:00
|
|
|
*/
|
|
|
|
rcu_read_lock();
|
2016-11-15 04:40:59 +08:00
|
|
|
request->engine->submit_request(request);
|
drm/i915: Use rcu instead of stop_machine in set_wedged
stop_machine is not really a locking primitive we should use, except
when the hw folks tell us the hw is broken and that's the only way to
work around it.
This patch tries to address the locking abuse of stop_machine() from
commit 20e4933c478a1ca694b38fa4ac44d99e659941f5
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Nov 22 14:41:21 2016 +0000
drm/i915: Stop the machine as we install the wedged submit_request handler
Chris said parts of the reasons for going with stop_machine() was that
it's no overhead for the fast-path. But these callbacks use irqsave
spinlocks and do a bunch of MMIO, and rcu_read_lock is _real_ fast.
To stay as close as possible to the stop_machine semantics we first
update all the submit function pointers to the nop handler, then call
synchronize_rcu() to make sure no new requests can be submitted. This
should give us exactly the huge barrier we want.
I pondered whether we should annotate engine->submit_request as __rcu
and use rcu_assign_pointer and rcu_dereference on it. But the reason
behind those is to make sure the compiler/cpu barriers are there for
when you have an actual data structure you point at, to make sure all
the writes are seen correctly on the read side. But we just have a
function pointer, and .text isn't changed, so no need for these
barriers and hence no need for annotations.
Unfortunately there's a complication with the call to
intel_engine_init_global_seqno:
- Without stop_machine we must hold the corresponding spinlock.
- Without stop_machine we must ensure that all requests are marked as
having failed with dma_fence_set_error() before we call it. That
means we need to split the nop request submission into two phases,
both synchronized with rcu:
1. Only stop submitting the requests to hw and mark them as failed.
2. After all pending requests in the scheduler/ring are suitably
marked up as failed and we can force complete them all, also force
complete by calling intel_engine_init_global_seqno().
This should fix the followwing lockdep splat:
======================================================
WARNING: possible circular locking dependency detected
4.14.0-rc3-CI-CI_DRM_3179+ #1 Tainted: G U
------------------------------------------------------
kworker/3:4/562 is trying to acquire lock:
(cpu_hotplug_lock.rw_sem){++++}, at: [<ffffffff8113d4bc>] stop_machine+0x1c/0x40
but task is already holding lock:
(&dev->struct_mutex){+.+.}, at: [<ffffffffa0136588>] i915_reset_device+0x1e8/0x260 [i915]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #6 (&dev->struct_mutex){+.+.}:
__lock_acquire+0x1420/0x15e0
lock_acquire+0xb0/0x200
__mutex_lock+0x86/0x9b0
mutex_lock_interruptible_nested+0x1b/0x20
i915_mutex_lock_interruptible+0x51/0x130 [i915]
i915_gem_fault+0x209/0x650 [i915]
__do_fault+0x1e/0x80
__handle_mm_fault+0xa08/0xed0
handle_mm_fault+0x156/0x300
__do_page_fault+0x2c5/0x570
do_page_fault+0x28/0x250
page_fault+0x22/0x30
-> #5 (&mm->mmap_sem){++++}:
__lock_acquire+0x1420/0x15e0
lock_acquire+0xb0/0x200
__might_fault+0x68/0x90
_copy_to_user+0x23/0x70
filldir+0xa5/0x120
dcache_readdir+0xf9/0x170
iterate_dir+0x69/0x1a0
SyS_getdents+0xa5/0x140
entry_SYSCALL_64_fastpath+0x1c/0xb1
-> #4 (&sb->s_type->i_mutex_key#5){++++}:
down_write+0x3b/0x70
handle_create+0xcb/0x1e0
devtmpfsd+0x139/0x180
kthread+0x152/0x190
ret_from_fork+0x27/0x40
-> #3 ((complete)&req.done){+.+.}:
__lock_acquire+0x1420/0x15e0
lock_acquire+0xb0/0x200
wait_for_common+0x58/0x210
wait_for_completion+0x1d/0x20
devtmpfs_create_node+0x13d/0x160
device_add+0x5eb/0x620
device_create_groups_vargs+0xe0/0xf0
device_create+0x3a/0x40
msr_device_create+0x2b/0x40
cpuhp_invoke_callback+0xc9/0xbf0
cpuhp_thread_fun+0x17b/0x240
smpboot_thread_fn+0x18a/0x280
kthread+0x152/0x190
ret_from_fork+0x27/0x40
-> #2 (cpuhp_state-up){+.+.}:
__lock_acquire+0x1420/0x15e0
lock_acquire+0xb0/0x200
cpuhp_issue_call+0x133/0x1c0
__cpuhp_setup_state_cpuslocked+0x139/0x2a0
__cpuhp_setup_state+0x46/0x60
page_writeback_init+0x43/0x67
pagecache_init+0x3d/0x42
start_kernel+0x3a8/0x3fc
x86_64_start_reservations+0x2a/0x2c
x86_64_start_kernel+0x6d/0x70
verify_cpu+0x0/0xfb
-> #1 (cpuhp_state_mutex){+.+.}:
__lock_acquire+0x1420/0x15e0
lock_acquire+0xb0/0x200
__mutex_lock+0x86/0x9b0
mutex_lock_nested+0x1b/0x20
__cpuhp_setup_state_cpuslocked+0x53/0x2a0
__cpuhp_setup_state+0x46/0x60
page_alloc_init+0x28/0x30
start_kernel+0x145/0x3fc
x86_64_start_reservations+0x2a/0x2c
x86_64_start_kernel+0x6d/0x70
verify_cpu+0x0/0xfb
-> #0 (cpu_hotplug_lock.rw_sem){++++}:
check_prev_add+0x430/0x840
__lock_acquire+0x1420/0x15e0
lock_acquire+0xb0/0x200
cpus_read_lock+0x3d/0xb0
stop_machine+0x1c/0x40
i915_gem_set_wedged+0x1a/0x20 [i915]
i915_reset+0xb9/0x230 [i915]
i915_reset_device+0x1f6/0x260 [i915]
i915_handle_error+0x2d8/0x430 [i915]
hangcheck_declare_hang+0xd3/0xf0 [i915]
i915_hangcheck_elapsed+0x262/0x2d0 [i915]
process_one_work+0x233/0x660
worker_thread+0x4e/0x3b0
kthread+0x152/0x190
ret_from_fork+0x27/0x40
other info that might help us debug this:
Chain exists of:
cpu_hotplug_lock.rw_sem --> &mm->mmap_sem --> &dev->struct_mutex
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&dev->struct_mutex);
lock(&mm->mmap_sem);
lock(&dev->struct_mutex);
lock(cpu_hotplug_lock.rw_sem);
*** DEADLOCK ***
3 locks held by kworker/3:4/562:
#0: ("events_long"){+.+.}, at: [<ffffffff8109c64a>] process_one_work+0x1aa/0x660
#1: ((&(&i915->gpu_error.hangcheck_work)->work)){+.+.}, at: [<ffffffff8109c64a>] process_one_work+0x1aa/0x660
#2: (&dev->struct_mutex){+.+.}, at: [<ffffffffa0136588>] i915_reset_device+0x1e8/0x260 [i915]
stack backtrace:
CPU: 3 PID: 562 Comm: kworker/3:4 Tainted: G U 4.14.0-rc3-CI-CI_DRM_3179+ #1
Hardware name: /NUC7i5BNB, BIOS BNKBL357.86A.0048.2017.0704.1415 07/04/2017
Workqueue: events_long i915_hangcheck_elapsed [i915]
Call Trace:
dump_stack+0x68/0x9f
print_circular_bug+0x235/0x3c0
? lockdep_init_map_crosslock+0x20/0x20
check_prev_add+0x430/0x840
? irq_work_queue+0x86/0xe0
? wake_up_klogd+0x53/0x70
__lock_acquire+0x1420/0x15e0
? __lock_acquire+0x1420/0x15e0
? lockdep_init_map_crosslock+0x20/0x20
lock_acquire+0xb0/0x200
? stop_machine+0x1c/0x40
? i915_gem_object_truncate+0x50/0x50 [i915]
cpus_read_lock+0x3d/0xb0
? stop_machine+0x1c/0x40
stop_machine+0x1c/0x40
i915_gem_set_wedged+0x1a/0x20 [i915]
i915_reset+0xb9/0x230 [i915]
i915_reset_device+0x1f6/0x260 [i915]
? gen8_gt_irq_ack+0x170/0x170 [i915]
? work_on_cpu_safe+0x60/0x60
i915_handle_error+0x2d8/0x430 [i915]
? vsnprintf+0xd1/0x4b0
? scnprintf+0x3a/0x70
hangcheck_declare_hang+0xd3/0xf0 [i915]
? intel_runtime_pm_put+0x56/0xa0 [i915]
i915_hangcheck_elapsed+0x262/0x2d0 [i915]
process_one_work+0x233/0x660
worker_thread+0x4e/0x3b0
kthread+0x152/0x190
? process_one_work+0x660/0x660
? kthread_create_on_node+0x40/0x40
ret_from_fork+0x27/0x40
Setting dangerous option reset - tainting kernel
i915 0000:00:02.0: Resetting chip after gpu hang
Setting dangerous option reset - tainting kernel
i915 0000:00:02.0: Resetting chip after gpu hang
v2: Have 1 global synchronize_rcu() barrier across all engines, and
improve commit message.
v3: We need to protect the seqno update with the timeline spinlock (in
set_wedged) to avoid racing with other updates of the seqno, like we
already do in nop_submit_request (Chris).
v4: Use two-phase sequence to plug the race Chris spotted where we can
complete requests before they're marked up with -EIO.
v5: Review from Chris:
- simplify nop_submit_request.
- Add comment to rcu_read_lock section.
- Align comments with the new style.
v6: Remove unused variable to appease CI.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102886
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103096
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Marta Lofstedt <marta.lofstedt@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171011091019.1425-1-daniel.vetter@ffwll.ch
2017-10-11 17:10:19 +08:00
|
|
|
rcu_read_unlock();
|
2016-11-25 21:17:17 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case FENCE_FREE:
|
2018-02-21 17:56:36 +08:00
|
|
|
i915_request_put(request);
|
2016-11-25 21:17:17 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2016-11-15 04:40:58 +08:00
|
|
|
return NOTIFY_DONE;
|
|
|
|
}
|
|
|
|
|
2016-08-03 05:50:26 +08:00
|
|
|
/**
|
2018-02-21 17:56:36 +08:00
|
|
|
* i915_request_alloc - allocate a request structure
|
2016-08-03 05:50:26 +08:00
|
|
|
*
|
|
|
|
* @engine: engine that we wish to issue the request on.
|
|
|
|
* @ctx: context that the request will be associated with.
|
|
|
|
*
|
|
|
|
* Returns a pointer to the allocated request if successful,
|
|
|
|
* or an error code if not.
|
|
|
|
*/
|
2018-02-21 17:56:36 +08:00
|
|
|
struct i915_request *
|
|
|
|
i915_request_alloc(struct intel_engine_cs *engine, struct i915_gem_context *ctx)
|
2016-07-20 16:21:08 +08:00
|
|
|
{
|
2018-02-21 17:56:36 +08:00
|
|
|
struct drm_i915_private *i915 = engine->i915;
|
|
|
|
struct i915_request *rq;
|
2018-05-18 05:26:32 +08:00
|
|
|
struct intel_context *ce;
|
2016-07-20 16:21:08 +08:00
|
|
|
int ret;
|
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
lockdep_assert_held(&i915->drm.struct_mutex);
|
2016-10-28 20:58:56 +08:00
|
|
|
|
2017-10-04 04:34:48 +08:00
|
|
|
/*
|
|
|
|
* Preempt contexts are reserved for exclusive use to inject a
|
|
|
|
* preemption context switch. They are never to be used for any trivial
|
|
|
|
* request!
|
|
|
|
*/
|
2018-02-21 17:56:36 +08:00
|
|
|
GEM_BUG_ON(ctx == i915->preempt_context);
|
2017-10-04 04:34:48 +08:00
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
/*
|
|
|
|
* ABI: Before userspace accesses the GPU (e.g. execbuffer), report
|
2017-01-15 00:23:33 +08:00
|
|
|
* EIO if the GPU is already wedged.
|
2016-07-20 16:21:08 +08:00
|
|
|
*/
|
2018-02-21 17:56:36 +08:00
|
|
|
if (i915_terminally_wedged(&i915->gpu_error))
|
2017-01-15 00:23:33 +08:00
|
|
|
return ERR_PTR(-EIO);
|
2016-07-20 16:21:08 +08:00
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
/*
|
|
|
|
* Pinning the contexts may generate requests in order to acquire
|
drm/i915: Unify active context tracking between legacy/execlists/guc
The requests conversion introduced a nasty bug where we could generate a
new request in the middle of constructing a request if we needed to idle
the system in order to evict space for a context. The request to idle
would be executed (and waited upon) before the current one, creating a
minor havoc in the seqno accounting, as we will consider the current
request to already be completed (prior to deferred seqno assignment) but
ring->last_retired_head would have been updated and still could allow
us to overwrite the current request before execution.
We also employed two different mechanisms to track the active context
until it was switched out. The legacy method allowed for waiting upon an
active context (it could forcibly evict any vma, including context's),
but the execlists method took a step backwards by pinning the vma for
the entire active lifespan of the context (the only way to evict was to
idle the entire GPU, not individual contexts). However, to circumvent
the tricky issue of locking (i.e. we cannot take struct_mutex at the
time of i915_gem_request_submit(), where we would want to move the
previous context onto the active tracker and unpin it), we take the
execlists approach and keep the contexts pinned until retirement.
The benefit of the execlists approach, more important for execlists than
legacy, was the reduction in work in pinning the context for each
request - as the context was kept pinned until idle, it could short
circuit the pinning for all active contexts.
We introduce new engine vfuncs to pin and unpin the context
respectively. The context is pinned at the start of the request, and
only unpinned when the following request is retired (this ensures that
the context is idle and coherent in main memory before we unpin it). We
move the engine->last_context tracking into the retirement itself
(rather than during request submission) in order to allow the submission
to be reordered or unwound without undue difficultly.
And finally an ulterior motive for unifying context handling was to
prepare for mock requests.
v2: Rename to last_retired_context, split out legacy_context tracking
for MI_SET_CONTEXT.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161218153724.8439-3-chris@chris-wilson.co.uk
2016-12-18 23:37:20 +08:00
|
|
|
* GGTT space, so do this first before we reserve a seqno for
|
|
|
|
* ourselves.
|
|
|
|
*/
|
2018-05-18 05:26:32 +08:00
|
|
|
ce = intel_context_pin(ctx, engine);
|
|
|
|
if (IS_ERR(ce))
|
|
|
|
return ERR_CAST(ce);
|
2016-10-28 20:58:56 +08:00
|
|
|
|
2018-04-30 21:15:00 +08:00
|
|
|
ret = reserve_gt(i915);
|
drm/i915: Unify active context tracking between legacy/execlists/guc
The requests conversion introduced a nasty bug where we could generate a
new request in the middle of constructing a request if we needed to idle
the system in order to evict space for a context. The request to idle
would be executed (and waited upon) before the current one, creating a
minor havoc in the seqno accounting, as we will consider the current
request to already be completed (prior to deferred seqno assignment) but
ring->last_retired_head would have been updated and still could allow
us to overwrite the current request before execution.
We also employed two different mechanisms to track the active context
until it was switched out. The legacy method allowed for waiting upon an
active context (it could forcibly evict any vma, including context's),
but the execlists method took a step backwards by pinning the vma for
the entire active lifespan of the context (the only way to evict was to
idle the entire GPU, not individual contexts). However, to circumvent
the tricky issue of locking (i.e. we cannot take struct_mutex at the
time of i915_gem_request_submit(), where we would want to move the
previous context onto the active tracker and unpin it), we take the
execlists approach and keep the contexts pinned until retirement.
The benefit of the execlists approach, more important for execlists than
legacy, was the reduction in work in pinning the context for each
request - as the context was kept pinned until idle, it could short
circuit the pinning for all active contexts.
We introduce new engine vfuncs to pin and unpin the context
respectively. The context is pinned at the start of the request, and
only unpinned when the following request is retired (this ensures that
the context is idle and coherent in main memory before we unpin it). We
move the engine->last_context tracking into the retirement itself
(rather than during request submission) in order to allow the submission
to be reordered or unwound without undue difficultly.
And finally an ulterior motive for unifying context handling was to
prepare for mock requests.
v2: Rename to last_retired_context, split out legacy_context tracking
for MI_SET_CONTEXT.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161218153724.8439-3-chris@chris-wilson.co.uk
2016-12-18 23:37:20 +08:00
|
|
|
if (ret)
|
|
|
|
goto err_unpin;
|
|
|
|
|
2018-05-18 05:26:32 +08:00
|
|
|
ret = intel_ring_wait_for_space(ce->ring, MIN_SPACE_FOR_ADD_REQUEST);
|
2017-11-20 18:20:02 +08:00
|
|
|
if (ret)
|
|
|
|
goto err_unreserve;
|
|
|
|
|
2018-04-30 21:15:02 +08:00
|
|
|
/* Move our oldest request to the slab-cache (if not in use!) */
|
2018-05-18 05:26:32 +08:00
|
|
|
rq = list_first_entry(&ce->ring->request_list, typeof(*rq), ring_link);
|
|
|
|
if (!list_is_last(&rq->ring_link, &ce->ring->request_list) &&
|
2018-05-04 03:51:15 +08:00
|
|
|
i915_request_completed(rq))
|
2018-02-21 17:56:36 +08:00
|
|
|
i915_request_retire(rq);
|
2016-07-20 16:21:09 +08:00
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
/*
|
|
|
|
* Beware: Dragons be flying overhead.
|
2016-08-09 16:23:34 +08:00
|
|
|
*
|
|
|
|
* We use RCU to look up requests in flight. The lookups may
|
|
|
|
* race with the request being allocated from the slab freelist.
|
|
|
|
* That is the request we are writing to here, may be in the process
|
2016-08-10 00:03:22 +08:00
|
|
|
* of being read by __i915_gem_active_get_rcu(). As such,
|
2016-08-09 16:23:34 +08:00
|
|
|
* we have to be very careful when overwriting the contents. During
|
|
|
|
* the RCU lookup, we change chase the request->engine pointer,
|
2016-10-28 20:58:49 +08:00
|
|
|
* read the request->global_seqno and increment the reference count.
|
2016-08-09 16:23:34 +08:00
|
|
|
*
|
|
|
|
* The reference count is incremented atomically. If it is zero,
|
|
|
|
* the lookup knows the request is unallocated and complete. Otherwise,
|
|
|
|
* it is either still in use, or has been reallocated and reset
|
2016-10-25 20:00:45 +08:00
|
|
|
* with dma_fence_init(). This increment is safe for release as we
|
|
|
|
* check that the request we have a reference to and matches the active
|
2016-08-09 16:23:34 +08:00
|
|
|
* request.
|
|
|
|
*
|
|
|
|
* Before we increment the refcount, we chase the request->engine
|
|
|
|
* pointer. We must not call kmem_cache_zalloc() or else we set
|
|
|
|
* that pointer to NULL and cause a crash during the lookup. If
|
|
|
|
* we see the request is completed (based on the value of the
|
|
|
|
* old engine and seqno), the lookup is complete and reports NULL.
|
|
|
|
* If we decide the request is not completed (new engine or seqno),
|
|
|
|
* then we grab a reference and double check that it is still the
|
|
|
|
* active request - which it won't be and restart the lookup.
|
|
|
|
*
|
|
|
|
* Do not use kmem_cache_zalloc() here!
|
|
|
|
*/
|
2018-02-21 17:56:36 +08:00
|
|
|
rq = kmem_cache_alloc(i915->requests,
|
|
|
|
GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN);
|
|
|
|
if (unlikely(!rq)) {
|
drm/i915: Limit the backpressure for i915_request allocation
If we try and fail to allocate a i915_request, we apply some
backpressure on the clients to throttle the memory allocations coming
from i915.ko. Currently, we wait until completely idle, but this is far
too heavy and leads to some situations where the only escape is to
declare a client hung and reset the GPU. The intent is to only ratelimit
the allocation requests and to allow ourselves to recycle requests and
memory from any long queues built up by a client hog.
Although the system memory is inherently a global resources, we don't
want to overly penalize an unlucky client to pay the price of reaping a
hog. To reduce the influence of one client on another, we can instead of
waiting for the entire GPU to idle, impose a barrier on the local client.
(One end goal for request allocation is for scalability to many
concurrent allocators; simultaneous execbufs.)
To prevent ourselves from getting caught out by long running requests
(requests that may never finish without userspace intervention, whom we
are blocking) we need to impose a finite timeout, ideally shorter than
hangcheck. A long time ago Paul McKenney suggested that RCU users should
ratelimit themselves using judicious use of cond_synchronize_rcu(). This
gives us the opportunity to reduce our indefinite wait for the GPU to
idle to a wait for the RCU grace period of the previous allocation along
this timeline to expire, satisfying both the local and finite properties
we desire for our ratelimiting.
There are still a few global steps (reclaim not least amongst those!)
when we exhaust the immediate slab pool, at least now the wait is itself
decoupled from struct_mutex for our glorious highly parallel future!
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106680
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180914080017.30308-1-chris@chris-wilson.co.uk
2018-09-14 16:00:15 +08:00
|
|
|
i915_retire_requests(i915);
|
|
|
|
|
2017-12-13 02:06:52 +08:00
|
|
|
/* Ratelimit ourselves to prevent oom from malicious clients */
|
drm/i915: Limit the backpressure for i915_request allocation
If we try and fail to allocate a i915_request, we apply some
backpressure on the clients to throttle the memory allocations coming
from i915.ko. Currently, we wait until completely idle, but this is far
too heavy and leads to some situations where the only escape is to
declare a client hung and reset the GPU. The intent is to only ratelimit
the allocation requests and to allow ourselves to recycle requests and
memory from any long queues built up by a client hog.
Although the system memory is inherently a global resources, we don't
want to overly penalize an unlucky client to pay the price of reaping a
hog. To reduce the influence of one client on another, we can instead of
waiting for the entire GPU to idle, impose a barrier on the local client.
(One end goal for request allocation is for scalability to many
concurrent allocators; simultaneous execbufs.)
To prevent ourselves from getting caught out by long running requests
(requests that may never finish without userspace intervention, whom we
are blocking) we need to impose a finite timeout, ideally shorter than
hangcheck. A long time ago Paul McKenney suggested that RCU users should
ratelimit themselves using judicious use of cond_synchronize_rcu(). This
gives us the opportunity to reduce our indefinite wait for the GPU to
idle to a wait for the RCU grace period of the previous allocation along
this timeline to expire, satisfying both the local and finite properties
we desire for our ratelimiting.
There are still a few global steps (reclaim not least amongst those!)
when we exhaust the immediate slab pool, at least now the wait is itself
decoupled from struct_mutex for our glorious highly parallel future!
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106680
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180914080017.30308-1-chris@chris-wilson.co.uk
2018-09-14 16:00:15 +08:00
|
|
|
rq = i915_gem_active_raw(&ce->ring->timeline->last_request,
|
|
|
|
&i915->drm.struct_mutex);
|
|
|
|
if (rq)
|
|
|
|
cond_synchronize_rcu(rq->rcustate);
|
2017-12-13 02:06:52 +08:00
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
rq = kmem_cache_alloc(i915->requests, GFP_KERNEL);
|
|
|
|
if (!rq) {
|
2017-12-13 02:06:52 +08:00
|
|
|
ret = -ENOMEM;
|
|
|
|
goto err_unreserve;
|
|
|
|
}
|
2016-10-28 20:58:56 +08:00
|
|
|
}
|
2016-07-20 16:21:08 +08:00
|
|
|
|
drm/i915: Limit the backpressure for i915_request allocation
If we try and fail to allocate a i915_request, we apply some
backpressure on the clients to throttle the memory allocations coming
from i915.ko. Currently, we wait until completely idle, but this is far
too heavy and leads to some situations where the only escape is to
declare a client hung and reset the GPU. The intent is to only ratelimit
the allocation requests and to allow ourselves to recycle requests and
memory from any long queues built up by a client hog.
Although the system memory is inherently a global resources, we don't
want to overly penalize an unlucky client to pay the price of reaping a
hog. To reduce the influence of one client on another, we can instead of
waiting for the entire GPU to idle, impose a barrier on the local client.
(One end goal for request allocation is for scalability to many
concurrent allocators; simultaneous execbufs.)
To prevent ourselves from getting caught out by long running requests
(requests that may never finish without userspace intervention, whom we
are blocking) we need to impose a finite timeout, ideally shorter than
hangcheck. A long time ago Paul McKenney suggested that RCU users should
ratelimit themselves using judicious use of cond_synchronize_rcu(). This
gives us the opportunity to reduce our indefinite wait for the GPU to
idle to a wait for the RCU grace period of the previous allocation along
this timeline to expire, satisfying both the local and finite properties
we desire for our ratelimiting.
There are still a few global steps (reclaim not least amongst those!)
when we exhaust the immediate slab pool, at least now the wait is itself
decoupled from struct_mutex for our glorious highly parallel future!
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106680
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180914080017.30308-1-chris@chris-wilson.co.uk
2018-09-14 16:00:15 +08:00
|
|
|
rq->rcustate = get_state_synchronize_rcu();
|
|
|
|
|
2018-05-03 00:38:38 +08:00
|
|
|
INIT_LIST_HEAD(&rq->active_list);
|
|
|
|
rq->i915 = i915;
|
|
|
|
rq->engine = engine;
|
2018-05-18 05:26:30 +08:00
|
|
|
rq->gem_context = ctx;
|
2018-05-18 05:26:32 +08:00
|
|
|
rq->hw_context = ce;
|
|
|
|
rq->ring = ce->ring;
|
|
|
|
rq->timeline = ce->ring->timeline;
|
2018-05-03 00:38:39 +08:00
|
|
|
GEM_BUG_ON(rq->timeline == &engine->timeline);
|
2016-10-28 20:58:46 +08:00
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
spin_lock_init(&rq->lock);
|
|
|
|
dma_fence_init(&rq->fence,
|
2016-10-25 20:00:45 +08:00
|
|
|
&i915_fence_ops,
|
2018-02-21 17:56:36 +08:00
|
|
|
&rq->lock,
|
|
|
|
rq->timeline->fence_context,
|
|
|
|
timeline_get_seqno(rq->timeline));
|
2016-07-20 16:21:11 +08:00
|
|
|
|
2016-11-25 21:17:17 +08:00
|
|
|
/* We bump the ref for the fence chain */
|
2018-02-21 17:56:36 +08:00
|
|
|
i915_sw_fence_init(&i915_request_get(rq)->submit, submit_notify);
|
|
|
|
init_waitqueue_head(&rq->execute);
|
2016-09-09 21:11:54 +08:00
|
|
|
|
2018-04-19 02:40:51 +08:00
|
|
|
i915_sched_node_init(&rq->sched);
|
2016-11-15 04:41:02 +08:00
|
|
|
|
2016-08-09 16:23:34 +08:00
|
|
|
/* No zalloc, must clear what we need by hand */
|
2018-02-21 17:56:36 +08:00
|
|
|
rq->global_seqno = 0;
|
|
|
|
rq->signaling.wait.seqno = 0;
|
|
|
|
rq->file_priv = NULL;
|
|
|
|
rq->batch = NULL;
|
|
|
|
rq->capture_list = NULL;
|
|
|
|
rq->waitboost = false;
|
2016-08-09 16:23:34 +08:00
|
|
|
|
2016-07-20 16:21:08 +08:00
|
|
|
/*
|
|
|
|
* Reserve space in the ring buffer for all the commands required to
|
|
|
|
* eventually emit this request. This is to guarantee that the
|
2018-02-21 17:56:36 +08:00
|
|
|
* i915_request_add() call can't fail. Note that the reserve may need
|
2016-07-20 16:21:08 +08:00
|
|
|
* to be redone if the request is not actually submitted straight
|
|
|
|
* away, e.g. because a GPU scheduler has deferred it.
|
|
|
|
*/
|
2018-02-21 17:56:36 +08:00
|
|
|
rq->reserved_space = MIN_SPACE_FOR_ADD_REQUEST;
|
|
|
|
GEM_BUG_ON(rq->reserved_space < engine->emit_breadcrumb_sz);
|
2016-07-20 16:21:08 +08:00
|
|
|
|
2017-11-20 18:20:01 +08:00
|
|
|
/*
|
|
|
|
* Record the position of the start of the request so that
|
2016-08-15 17:48:40 +08:00
|
|
|
* should we detect the updated seqno part-way through the
|
|
|
|
* GPU processing the request, we never over-estimate the
|
|
|
|
* position of the head.
|
|
|
|
*/
|
2018-02-21 17:56:36 +08:00
|
|
|
rq->head = rq->ring->emit;
|
2016-08-15 17:48:40 +08:00
|
|
|
|
2017-11-20 18:20:01 +08:00
|
|
|
/* Unconditionally invalidate GPU caches and TLBs. */
|
2018-02-21 17:56:36 +08:00
|
|
|
ret = engine->emit_flush(rq, EMIT_INVALIDATE);
|
2017-11-20 18:20:01 +08:00
|
|
|
if (ret)
|
2017-11-23 23:26:30 +08:00
|
|
|
goto err_unwind;
|
2017-11-20 18:20:01 +08:00
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
ret = engine->request_alloc(rq);
|
2017-11-23 23:26:30 +08:00
|
|
|
if (ret)
|
|
|
|
goto err_unwind;
|
2017-11-20 18:20:01 +08:00
|
|
|
|
2018-04-30 21:15:02 +08:00
|
|
|
/* Keep a second pin for the dual retirement along engine and ring */
|
2018-05-18 05:26:32 +08:00
|
|
|
__intel_context_pin(ce);
|
2018-04-30 21:15:02 +08:00
|
|
|
|
2018-06-11 19:08:44 +08:00
|
|
|
rq->infix = rq->ring->emit; /* end of header; start of user payload */
|
|
|
|
|
2017-02-23 15:44:08 +08:00
|
|
|
/* Check that we didn't interrupt ourselves with a new request */
|
2018-02-21 17:56:36 +08:00
|
|
|
GEM_BUG_ON(rq->timeline->seqno != rq->fence.seqno);
|
|
|
|
return rq;
|
2016-07-20 16:21:08 +08:00
|
|
|
|
2017-11-23 23:26:30 +08:00
|
|
|
err_unwind:
|
2018-05-18 05:26:32 +08:00
|
|
|
ce->ring->emit = rq->head;
|
2017-11-23 23:26:30 +08:00
|
|
|
|
2016-11-25 21:17:16 +08:00
|
|
|
/* Make sure we didn't add ourselves to external state before freeing */
|
2018-02-21 17:56:36 +08:00
|
|
|
GEM_BUG_ON(!list_empty(&rq->active_list));
|
2018-04-19 02:40:51 +08:00
|
|
|
GEM_BUG_ON(!list_empty(&rq->sched.signalers_list));
|
|
|
|
GEM_BUG_ON(!list_empty(&rq->sched.waiters_list));
|
2016-11-25 21:17:16 +08:00
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
kmem_cache_free(i915->requests, rq);
|
2016-10-28 20:58:56 +08:00
|
|
|
err_unreserve:
|
2018-04-30 21:15:00 +08:00
|
|
|
unreserve_gt(i915);
|
drm/i915: Unify active context tracking between legacy/execlists/guc
The requests conversion introduced a nasty bug where we could generate a
new request in the middle of constructing a request if we needed to idle
the system in order to evict space for a context. The request to idle
would be executed (and waited upon) before the current one, creating a
minor havoc in the seqno accounting, as we will consider the current
request to already be completed (prior to deferred seqno assignment) but
ring->last_retired_head would have been updated and still could allow
us to overwrite the current request before execution.
We also employed two different mechanisms to track the active context
until it was switched out. The legacy method allowed for waiting upon an
active context (it could forcibly evict any vma, including context's),
but the execlists method took a step backwards by pinning the vma for
the entire active lifespan of the context (the only way to evict was to
idle the entire GPU, not individual contexts). However, to circumvent
the tricky issue of locking (i.e. we cannot take struct_mutex at the
time of i915_gem_request_submit(), where we would want to move the
previous context onto the active tracker and unpin it), we take the
execlists approach and keep the contexts pinned until retirement.
The benefit of the execlists approach, more important for execlists than
legacy, was the reduction in work in pinning the context for each
request - as the context was kept pinned until idle, it could short
circuit the pinning for all active contexts.
We introduce new engine vfuncs to pin and unpin the context
respectively. The context is pinned at the start of the request, and
only unpinned when the following request is retired (this ensures that
the context is idle and coherent in main memory before we unpin it). We
move the engine->last_context tracking into the retirement itself
(rather than during request submission) in order to allow the submission
to be reordered or unwound without undue difficultly.
And finally an ulterior motive for unifying context handling was to
prepare for mock requests.
v2: Rename to last_retired_context, split out legacy_context tracking
for MI_SET_CONTEXT.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161218153724.8439-3-chris@chris-wilson.co.uk
2016-12-18 23:37:20 +08:00
|
|
|
err_unpin:
|
2018-05-18 05:26:32 +08:00
|
|
|
intel_context_unpin(ce);
|
2016-08-03 05:50:26 +08:00
|
|
|
return ERR_PTR(ret);
|
2016-07-20 16:21:08 +08:00
|
|
|
}
|
|
|
|
|
2016-09-09 21:11:56 +08:00
|
|
|
static int
|
2018-02-21 17:56:36 +08:00
|
|
|
i915_request_await_request(struct i915_request *to, struct i915_request *from)
|
2016-09-09 21:11:56 +08:00
|
|
|
{
|
2016-10-28 20:58:53 +08:00
|
|
|
int ret;
|
2016-09-09 21:11:56 +08:00
|
|
|
|
|
|
|
GEM_BUG_ON(to == from);
|
2017-05-03 17:39:20 +08:00
|
|
|
GEM_BUG_ON(to->timeline == from->timeline);
|
2016-09-09 21:11:56 +08:00
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
if (i915_request_completed(from))
|
2017-04-22 16:15:37 +08:00
|
|
|
return 0;
|
|
|
|
|
2016-11-15 04:41:02 +08:00
|
|
|
if (to->engine->schedule) {
|
2018-04-19 02:40:51 +08:00
|
|
|
ret = i915_sched_node_add_dependency(to->i915,
|
|
|
|
&to->sched,
|
|
|
|
&from->sched);
|
2016-11-15 04:41:02 +08:00
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2016-10-28 20:58:46 +08:00
|
|
|
if (to->engine == from->engine) {
|
|
|
|
ret = i915_sw_fence_await_sw_fence_gfp(&to->submit,
|
|
|
|
&from->submit,
|
2017-12-13 02:06:51 +08:00
|
|
|
I915_FENCE_GFP);
|
2016-10-28 20:58:46 +08:00
|
|
|
return ret < 0 ? ret : 0;
|
|
|
|
}
|
|
|
|
|
2017-06-08 19:14:05 +08:00
|
|
|
if (to->engine->semaphore.sync_to) {
|
|
|
|
u32 seqno;
|
2016-10-28 20:58:49 +08:00
|
|
|
|
2017-06-08 19:14:05 +08:00
|
|
|
GEM_BUG_ON(!from->engine->semaphore.signal);
|
2017-05-03 17:39:23 +08:00
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
seqno = i915_request_global_seqno(from);
|
2017-06-08 19:14:05 +08:00
|
|
|
if (!seqno)
|
2017-05-03 17:39:23 +08:00
|
|
|
goto await_dma_fence;
|
2017-05-03 17:39:24 +08:00
|
|
|
|
2017-05-03 17:39:23 +08:00
|
|
|
if (seqno <= to->timeline->global_sync[from->engine->id])
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
trace_i915_gem_ring_sync_to(to, from);
|
2016-09-09 21:11:56 +08:00
|
|
|
ret = to->engine->semaphore.sync_to(to, from);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2017-05-03 17:39:23 +08:00
|
|
|
|
|
|
|
to->timeline->global_sync[from->engine->id] = seqno;
|
2017-06-08 19:14:05 +08:00
|
|
|
return 0;
|
2016-09-09 21:11:56 +08:00
|
|
|
}
|
|
|
|
|
2017-05-03 17:39:23 +08:00
|
|
|
await_dma_fence:
|
|
|
|
ret = i915_sw_fence_await_dma_fence(&to->submit,
|
|
|
|
&from->fence, 0,
|
2017-12-13 02:06:51 +08:00
|
|
|
I915_FENCE_GFP);
|
2017-05-03 17:39:23 +08:00
|
|
|
return ret < 0 ? ret : 0;
|
2016-09-09 21:11:56 +08:00
|
|
|
}
|
|
|
|
|
2016-10-28 20:58:24 +08:00
|
|
|
int
|
2018-02-21 17:56:36 +08:00
|
|
|
i915_request_await_dma_fence(struct i915_request *rq, struct dma_fence *fence)
|
2016-10-28 20:58:24 +08:00
|
|
|
{
|
2017-05-03 17:39:19 +08:00
|
|
|
struct dma_fence **child = &fence;
|
|
|
|
unsigned int nchild = 1;
|
2016-10-28 20:58:24 +08:00
|
|
|
int ret;
|
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
/*
|
|
|
|
* Note that if the fence-array was created in signal-on-any mode,
|
2016-10-28 20:58:24 +08:00
|
|
|
* we should *not* decompose it into its individual fences. However,
|
|
|
|
* we don't currently store which mode the fence-array is operating
|
|
|
|
* in. Fortunately, the only user of signal-on-any is private to
|
|
|
|
* amdgpu and we should not see any incoming fence-array from
|
|
|
|
* sync-file being in signal-on-any mode.
|
|
|
|
*/
|
2017-05-03 17:39:19 +08:00
|
|
|
if (dma_fence_is_array(fence)) {
|
|
|
|
struct dma_fence_array *array = to_dma_fence_array(fence);
|
|
|
|
|
|
|
|
child = array->fences;
|
|
|
|
nchild = array->num_fences;
|
|
|
|
GEM_BUG_ON(!nchild);
|
|
|
|
}
|
2016-10-28 20:58:24 +08:00
|
|
|
|
2017-05-03 17:39:19 +08:00
|
|
|
do {
|
|
|
|
fence = *child++;
|
|
|
|
if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
|
|
|
|
continue;
|
2016-10-28 20:58:24 +08:00
|
|
|
|
2017-05-03 17:39:20 +08:00
|
|
|
/*
|
|
|
|
* Requests on the same timeline are explicitly ordered, along
|
2018-02-21 17:56:36 +08:00
|
|
|
* with their dependencies, by i915_request_add() which ensures
|
2017-05-03 17:39:20 +08:00
|
|
|
* that requests are submitted in-order through each ring.
|
|
|
|
*/
|
2018-02-21 17:56:36 +08:00
|
|
|
if (fence->context == rq->fence.context)
|
2017-05-03 17:39:20 +08:00
|
|
|
continue;
|
|
|
|
|
2017-05-03 17:39:21 +08:00
|
|
|
/* Squash repeated waits to the same timelines */
|
2018-02-21 17:56:36 +08:00
|
|
|
if (fence->context != rq->i915->mm.unordered_timeline &&
|
2018-05-03 00:38:39 +08:00
|
|
|
i915_timeline_sync_is_later(rq->timeline, fence))
|
2017-05-03 17:39:21 +08:00
|
|
|
continue;
|
|
|
|
|
2017-05-03 17:39:19 +08:00
|
|
|
if (dma_fence_is_i915(fence))
|
2018-02-21 17:56:36 +08:00
|
|
|
ret = i915_request_await_request(rq, to_request(fence));
|
2016-10-28 20:58:24 +08:00
|
|
|
else
|
2018-02-21 17:56:36 +08:00
|
|
|
ret = i915_sw_fence_await_dma_fence(&rq->submit, fence,
|
2017-05-03 17:39:19 +08:00
|
|
|
I915_FENCE_TIMEOUT,
|
2017-12-13 02:06:51 +08:00
|
|
|
I915_FENCE_GFP);
|
2016-10-28 20:58:24 +08:00
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
2017-05-03 17:39:21 +08:00
|
|
|
|
|
|
|
/* Record the latest fence used against each timeline */
|
2018-02-21 17:56:36 +08:00
|
|
|
if (fence->context != rq->i915->mm.unordered_timeline)
|
2018-05-03 00:38:39 +08:00
|
|
|
i915_timeline_sync_set(rq->timeline, fence);
|
2017-05-03 17:39:19 +08:00
|
|
|
} while (--nchild);
|
2016-10-28 20:58:24 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-09-09 21:11:56 +08:00
|
|
|
/**
|
2018-02-21 17:56:36 +08:00
|
|
|
* i915_request_await_object - set this request to (async) wait upon a bo
|
2016-09-09 21:11:56 +08:00
|
|
|
* @to: request we are wishing to use
|
|
|
|
* @obj: object which may be in use on another ring.
|
2018-02-08 19:14:53 +08:00
|
|
|
* @write: whether the wait is on behalf of a writer
|
2016-09-09 21:11:56 +08:00
|
|
|
*
|
|
|
|
* This code is meant to abstract object synchronization with the GPU.
|
|
|
|
* Conceptually we serialise writes between engines inside the GPU.
|
|
|
|
* We only allow one engine to write into a buffer at any time, but
|
|
|
|
* multiple readers. To ensure each has a coherent view of memory, we must:
|
|
|
|
*
|
|
|
|
* - If there is an outstanding write request to the object, the new
|
|
|
|
* request must wait for it to complete (either CPU or in hw, requests
|
|
|
|
* on the same ring will be naturally ordered).
|
|
|
|
*
|
|
|
|
* - If we are a write request (pending_write_domain is set), the new
|
|
|
|
* request must wait for outstanding read requests to complete.
|
|
|
|
*
|
|
|
|
* Returns 0 if successful, else propagates up the lower layer error.
|
|
|
|
*/
|
|
|
|
int
|
2018-02-21 17:56:36 +08:00
|
|
|
i915_request_await_object(struct i915_request *to,
|
|
|
|
struct drm_i915_gem_object *obj,
|
|
|
|
bool write)
|
2016-09-09 21:11:56 +08:00
|
|
|
{
|
drm/i915: Move GEM activity tracking into a common struct reservation_object
In preparation to support many distinct timelines, we need to expand the
activity tracking on the GEM object to handle more than just a request
per engine. We already use the struct reservation_object on the dma-buf
to handle many fence contexts, so integrating that into the GEM object
itself is the preferred solution. (For example, we can now share the same
reservation_object between every consumer/producer using this buffer and
skip the manual import/export via dma-buf.)
v2: Reimplement busy-ioctl (by walking the reservation object), postpone
the ABI change for another day. Similarly use the reservation object to
find the last_write request (if active and from i915) for choosing
display CS flips.
Caveats:
* busy-ioctl: busy-ioctl only reports on the native fences, it will not
warn of stalls (in set-domain-ioctl, pread/pwrite etc) if the object is
being rendered to by external fences. It also will not report the same
busy state as wait-ioctl (or polling on the dma-buf) in the same
circumstances. On the plus side, it does retain reporting of which
*i915* engines are engaged with this object.
* non-blocking atomic modesets take a step backwards as the wait for
render completion blocks the ioctl. This is fixed in a subsequent
patch to use a fence instead for awaiting on the rendering, see
"drm/i915: Restore nonblocking awaits for modesetting"
* dynamic array manipulation for shared-fences in reservation is slower
than the previous lockless static assignment (e.g. gem_exec_lut_handle
runtime on ivb goes from 42s to 66s), mainly due to atomic operations
(maintaining the fence refcounts).
* loss of object-level retirement callbacks, emulated by VMA retirement
tracking.
* minor loss of object-level last activity information from debugfs,
could be replaced with per-vma information if desired
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161028125858.23563-21-chris@chris-wilson.co.uk
2016-10-28 20:58:44 +08:00
|
|
|
struct dma_fence *excl;
|
|
|
|
int ret = 0;
|
2016-09-09 21:11:56 +08:00
|
|
|
|
|
|
|
if (write) {
|
drm/i915: Move GEM activity tracking into a common struct reservation_object
In preparation to support many distinct timelines, we need to expand the
activity tracking on the GEM object to handle more than just a request
per engine. We already use the struct reservation_object on the dma-buf
to handle many fence contexts, so integrating that into the GEM object
itself is the preferred solution. (For example, we can now share the same
reservation_object between every consumer/producer using this buffer and
skip the manual import/export via dma-buf.)
v2: Reimplement busy-ioctl (by walking the reservation object), postpone
the ABI change for another day. Similarly use the reservation object to
find the last_write request (if active and from i915) for choosing
display CS flips.
Caveats:
* busy-ioctl: busy-ioctl only reports on the native fences, it will not
warn of stalls (in set-domain-ioctl, pread/pwrite etc) if the object is
being rendered to by external fences. It also will not report the same
busy state as wait-ioctl (or polling on the dma-buf) in the same
circumstances. On the plus side, it does retain reporting of which
*i915* engines are engaged with this object.
* non-blocking atomic modesets take a step backwards as the wait for
render completion blocks the ioctl. This is fixed in a subsequent
patch to use a fence instead for awaiting on the rendering, see
"drm/i915: Restore nonblocking awaits for modesetting"
* dynamic array manipulation for shared-fences in reservation is slower
than the previous lockless static assignment (e.g. gem_exec_lut_handle
runtime on ivb goes from 42s to 66s), mainly due to atomic operations
(maintaining the fence refcounts).
* loss of object-level retirement callbacks, emulated by VMA retirement
tracking.
* minor loss of object-level last activity information from debugfs,
could be replaced with per-vma information if desired
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161028125858.23563-21-chris@chris-wilson.co.uk
2016-10-28 20:58:44 +08:00
|
|
|
struct dma_fence **shared;
|
|
|
|
unsigned int count, i;
|
|
|
|
|
|
|
|
ret = reservation_object_get_fences_rcu(obj->resv,
|
|
|
|
&excl, &count, &shared);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
for (i = 0; i < count; i++) {
|
2018-02-21 17:56:36 +08:00
|
|
|
ret = i915_request_await_dma_fence(to, shared[i]);
|
drm/i915: Move GEM activity tracking into a common struct reservation_object
In preparation to support many distinct timelines, we need to expand the
activity tracking on the GEM object to handle more than just a request
per engine. We already use the struct reservation_object on the dma-buf
to handle many fence contexts, so integrating that into the GEM object
itself is the preferred solution. (For example, we can now share the same
reservation_object between every consumer/producer using this buffer and
skip the manual import/export via dma-buf.)
v2: Reimplement busy-ioctl (by walking the reservation object), postpone
the ABI change for another day. Similarly use the reservation object to
find the last_write request (if active and from i915) for choosing
display CS flips.
Caveats:
* busy-ioctl: busy-ioctl only reports on the native fences, it will not
warn of stalls (in set-domain-ioctl, pread/pwrite etc) if the object is
being rendered to by external fences. It also will not report the same
busy state as wait-ioctl (or polling on the dma-buf) in the same
circumstances. On the plus side, it does retain reporting of which
*i915* engines are engaged with this object.
* non-blocking atomic modesets take a step backwards as the wait for
render completion blocks the ioctl. This is fixed in a subsequent
patch to use a fence instead for awaiting on the rendering, see
"drm/i915: Restore nonblocking awaits for modesetting"
* dynamic array manipulation for shared-fences in reservation is slower
than the previous lockless static assignment (e.g. gem_exec_lut_handle
runtime on ivb goes from 42s to 66s), mainly due to atomic operations
(maintaining the fence refcounts).
* loss of object-level retirement callbacks, emulated by VMA retirement
tracking.
* minor loss of object-level last activity information from debugfs,
could be replaced with per-vma information if desired
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161028125858.23563-21-chris@chris-wilson.co.uk
2016-10-28 20:58:44 +08:00
|
|
|
if (ret)
|
|
|
|
break;
|
|
|
|
|
|
|
|
dma_fence_put(shared[i]);
|
|
|
|
}
|
|
|
|
|
|
|
|
for (; i < count; i++)
|
|
|
|
dma_fence_put(shared[i]);
|
|
|
|
kfree(shared);
|
2016-09-09 21:11:56 +08:00
|
|
|
} else {
|
drm/i915: Move GEM activity tracking into a common struct reservation_object
In preparation to support many distinct timelines, we need to expand the
activity tracking on the GEM object to handle more than just a request
per engine. We already use the struct reservation_object on the dma-buf
to handle many fence contexts, so integrating that into the GEM object
itself is the preferred solution. (For example, we can now share the same
reservation_object between every consumer/producer using this buffer and
skip the manual import/export via dma-buf.)
v2: Reimplement busy-ioctl (by walking the reservation object), postpone
the ABI change for another day. Similarly use the reservation object to
find the last_write request (if active and from i915) for choosing
display CS flips.
Caveats:
* busy-ioctl: busy-ioctl only reports on the native fences, it will not
warn of stalls (in set-domain-ioctl, pread/pwrite etc) if the object is
being rendered to by external fences. It also will not report the same
busy state as wait-ioctl (or polling on the dma-buf) in the same
circumstances. On the plus side, it does retain reporting of which
*i915* engines are engaged with this object.
* non-blocking atomic modesets take a step backwards as the wait for
render completion blocks the ioctl. This is fixed in a subsequent
patch to use a fence instead for awaiting on the rendering, see
"drm/i915: Restore nonblocking awaits for modesetting"
* dynamic array manipulation for shared-fences in reservation is slower
than the previous lockless static assignment (e.g. gem_exec_lut_handle
runtime on ivb goes from 42s to 66s), mainly due to atomic operations
(maintaining the fence refcounts).
* loss of object-level retirement callbacks, emulated by VMA retirement
tracking.
* minor loss of object-level last activity information from debugfs,
could be replaced with per-vma information if desired
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161028125858.23563-21-chris@chris-wilson.co.uk
2016-10-28 20:58:44 +08:00
|
|
|
excl = reservation_object_get_excl_rcu(obj->resv);
|
2016-09-09 21:11:56 +08:00
|
|
|
}
|
|
|
|
|
drm/i915: Move GEM activity tracking into a common struct reservation_object
In preparation to support many distinct timelines, we need to expand the
activity tracking on the GEM object to handle more than just a request
per engine. We already use the struct reservation_object on the dma-buf
to handle many fence contexts, so integrating that into the GEM object
itself is the preferred solution. (For example, we can now share the same
reservation_object between every consumer/producer using this buffer and
skip the manual import/export via dma-buf.)
v2: Reimplement busy-ioctl (by walking the reservation object), postpone
the ABI change for another day. Similarly use the reservation object to
find the last_write request (if active and from i915) for choosing
display CS flips.
Caveats:
* busy-ioctl: busy-ioctl only reports on the native fences, it will not
warn of stalls (in set-domain-ioctl, pread/pwrite etc) if the object is
being rendered to by external fences. It also will not report the same
busy state as wait-ioctl (or polling on the dma-buf) in the same
circumstances. On the plus side, it does retain reporting of which
*i915* engines are engaged with this object.
* non-blocking atomic modesets take a step backwards as the wait for
render completion blocks the ioctl. This is fixed in a subsequent
patch to use a fence instead for awaiting on the rendering, see
"drm/i915: Restore nonblocking awaits for modesetting"
* dynamic array manipulation for shared-fences in reservation is slower
than the previous lockless static assignment (e.g. gem_exec_lut_handle
runtime on ivb goes from 42s to 66s), mainly due to atomic operations
(maintaining the fence refcounts).
* loss of object-level retirement callbacks, emulated by VMA retirement
tracking.
* minor loss of object-level last activity information from debugfs,
could be replaced with per-vma information if desired
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161028125858.23563-21-chris@chris-wilson.co.uk
2016-10-28 20:58:44 +08:00
|
|
|
if (excl) {
|
|
|
|
if (ret == 0)
|
2018-02-21 17:56:36 +08:00
|
|
|
ret = i915_request_await_dma_fence(to, excl);
|
2016-09-09 21:11:56 +08:00
|
|
|
|
drm/i915: Move GEM activity tracking into a common struct reservation_object
In preparation to support many distinct timelines, we need to expand the
activity tracking on the GEM object to handle more than just a request
per engine. We already use the struct reservation_object on the dma-buf
to handle many fence contexts, so integrating that into the GEM object
itself is the preferred solution. (For example, we can now share the same
reservation_object between every consumer/producer using this buffer and
skip the manual import/export via dma-buf.)
v2: Reimplement busy-ioctl (by walking the reservation object), postpone
the ABI change for another day. Similarly use the reservation object to
find the last_write request (if active and from i915) for choosing
display CS flips.
Caveats:
* busy-ioctl: busy-ioctl only reports on the native fences, it will not
warn of stalls (in set-domain-ioctl, pread/pwrite etc) if the object is
being rendered to by external fences. It also will not report the same
busy state as wait-ioctl (or polling on the dma-buf) in the same
circumstances. On the plus side, it does retain reporting of which
*i915* engines are engaged with this object.
* non-blocking atomic modesets take a step backwards as the wait for
render completion blocks the ioctl. This is fixed in a subsequent
patch to use a fence instead for awaiting on the rendering, see
"drm/i915: Restore nonblocking awaits for modesetting"
* dynamic array manipulation for shared-fences in reservation is slower
than the previous lockless static assignment (e.g. gem_exec_lut_handle
runtime on ivb goes from 42s to 66s), mainly due to atomic operations
(maintaining the fence refcounts).
* loss of object-level retirement callbacks, emulated by VMA retirement
tracking.
* minor loss of object-level last activity information from debugfs,
could be replaced with per-vma information if desired
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161028125858.23563-21-chris@chris-wilson.co.uk
2016-10-28 20:58:44 +08:00
|
|
|
dma_fence_put(excl);
|
2016-09-09 21:11:56 +08:00
|
|
|
}
|
|
|
|
|
drm/i915: Move GEM activity tracking into a common struct reservation_object
In preparation to support many distinct timelines, we need to expand the
activity tracking on the GEM object to handle more than just a request
per engine. We already use the struct reservation_object on the dma-buf
to handle many fence contexts, so integrating that into the GEM object
itself is the preferred solution. (For example, we can now share the same
reservation_object between every consumer/producer using this buffer and
skip the manual import/export via dma-buf.)
v2: Reimplement busy-ioctl (by walking the reservation object), postpone
the ABI change for another day. Similarly use the reservation object to
find the last_write request (if active and from i915) for choosing
display CS flips.
Caveats:
* busy-ioctl: busy-ioctl only reports on the native fences, it will not
warn of stalls (in set-domain-ioctl, pread/pwrite etc) if the object is
being rendered to by external fences. It also will not report the same
busy state as wait-ioctl (or polling on the dma-buf) in the same
circumstances. On the plus side, it does retain reporting of which
*i915* engines are engaged with this object.
* non-blocking atomic modesets take a step backwards as the wait for
render completion blocks the ioctl. This is fixed in a subsequent
patch to use a fence instead for awaiting on the rendering, see
"drm/i915: Restore nonblocking awaits for modesetting"
* dynamic array manipulation for shared-fences in reservation is slower
than the previous lockless static assignment (e.g. gem_exec_lut_handle
runtime on ivb goes from 42s to 66s), mainly due to atomic operations
(maintaining the fence refcounts).
* loss of object-level retirement callbacks, emulated by VMA retirement
tracking.
* minor loss of object-level last activity information from debugfs,
could be replaced with per-vma information if desired
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161028125858.23563-21-chris@chris-wilson.co.uk
2016-10-28 20:58:44 +08:00
|
|
|
return ret;
|
2016-09-09 21:11:56 +08:00
|
|
|
}
|
|
|
|
|
2018-07-06 18:39:43 +08:00
|
|
|
void i915_request_skip(struct i915_request *rq, int error)
|
|
|
|
{
|
|
|
|
void *vaddr = rq->ring->vaddr;
|
|
|
|
u32 head;
|
|
|
|
|
|
|
|
GEM_BUG_ON(!IS_ERR_VALUE((long)error));
|
|
|
|
dma_fence_set_error(&rq->fence, error);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* As this request likely depends on state from the lost
|
|
|
|
* context, clear out all the user operations leaving the
|
|
|
|
* breadcrumb at the end (so we get the fence notifications).
|
|
|
|
*/
|
|
|
|
head = rq->infix;
|
|
|
|
if (rq->postfix < head) {
|
|
|
|
memset(vaddr + head, 0, rq->ring->size - head);
|
|
|
|
head = 0;
|
|
|
|
}
|
|
|
|
memset(vaddr + head, 0, rq->postfix - head);
|
|
|
|
}
|
|
|
|
|
2016-07-20 16:21:08 +08:00
|
|
|
/*
|
|
|
|
* NB: This function is not allowed to fail. Doing so would mean the the
|
|
|
|
* request is not being tracked for completion but the work itself is
|
|
|
|
* going to happen on the hardware. This would be a Bad Thing(tm).
|
|
|
|
*/
|
2018-06-12 18:51:35 +08:00
|
|
|
void i915_request_add(struct i915_request *request)
|
2016-07-20 16:21:08 +08:00
|
|
|
{
|
2016-08-15 17:48:46 +08:00
|
|
|
struct intel_engine_cs *engine = request->engine;
|
2018-05-03 00:38:39 +08:00
|
|
|
struct i915_timeline *timeline = request->timeline;
|
2018-05-18 05:26:32 +08:00
|
|
|
struct intel_ring *ring = request->ring;
|
2018-02-21 17:56:36 +08:00
|
|
|
struct i915_request *prev;
|
2017-02-14 19:32:42 +08:00
|
|
|
u32 *cs;
|
2016-07-20 16:21:08 +08:00
|
|
|
|
2018-03-15 21:14:50 +08:00
|
|
|
GEM_TRACE("%s fence %llx:%d\n",
|
|
|
|
engine->name, request->fence.context, request->fence.seqno);
|
|
|
|
|
2016-10-28 20:58:32 +08:00
|
|
|
lockdep_assert_held(&request->i915->drm.struct_mutex);
|
2018-02-21 17:56:36 +08:00
|
|
|
trace_i915_request_add(request);
|
2016-09-09 21:11:55 +08:00
|
|
|
|
2018-02-07 16:43:50 +08:00
|
|
|
/*
|
|
|
|
* Make sure that no request gazumped us - if it was allocated after
|
2018-02-21 17:56:36 +08:00
|
|
|
* our i915_request_alloc() and called __i915_request_add() before
|
2017-01-11 22:08:58 +08:00
|
|
|
* us, the timeline will hold its seqno which is later than ours.
|
|
|
|
*/
|
2017-02-23 15:44:08 +08:00
|
|
|
GEM_BUG_ON(timeline->seqno != request->fence.seqno);
|
2017-01-11 22:08:58 +08:00
|
|
|
|
2016-07-20 16:21:08 +08:00
|
|
|
/*
|
|
|
|
* To ensure that this call will not fail, space for its emissions
|
|
|
|
* should already have been reserved in the ring buffer. Let the ring
|
|
|
|
* know that it is time to use that space up.
|
|
|
|
*/
|
|
|
|
request->reserved_space = 0;
|
2018-06-12 18:51:35 +08:00
|
|
|
engine->emit_flush(request, EMIT_FLUSH);
|
2016-07-20 16:21:08 +08:00
|
|
|
|
2018-02-07 16:43:50 +08:00
|
|
|
/*
|
|
|
|
* Record the position of the start of the breadcrumb so that
|
2016-07-20 16:21:08 +08:00
|
|
|
* should we detect the updated seqno part-way through the
|
|
|
|
* GPU processing the request, we never over-estimate the
|
2016-08-15 17:48:40 +08:00
|
|
|
* position of the ring's HEAD.
|
2016-07-20 16:21:08 +08:00
|
|
|
*/
|
2017-02-14 19:32:42 +08:00
|
|
|
cs = intel_ring_begin(request, engine->emit_breadcrumb_sz);
|
|
|
|
GEM_BUG_ON(IS_ERR(cs));
|
|
|
|
request->postfix = intel_ring_offset(request, cs);
|
2016-07-20 16:21:08 +08:00
|
|
|
|
2018-02-07 16:43:50 +08:00
|
|
|
/*
|
|
|
|
* Seal the request and mark it as pending execution. Note that
|
2016-09-09 21:11:55 +08:00
|
|
|
* we may inspect this state, without holding any locks, during
|
|
|
|
* hangcheck. Hence we apply the barrier to ensure that we do not
|
|
|
|
* see a more recent value in the hws than we are tracking.
|
|
|
|
*/
|
2016-09-09 21:12:00 +08:00
|
|
|
|
2016-10-28 20:58:46 +08:00
|
|
|
prev = i915_gem_active_raw(&timeline->last_request,
|
2016-09-09 21:12:00 +08:00
|
|
|
&request->i915->drm.struct_mutex);
|
2018-02-21 17:56:36 +08:00
|
|
|
if (prev && !i915_request_completed(prev)) {
|
2016-09-09 21:12:00 +08:00
|
|
|
i915_sw_fence_await_sw_fence(&request->submit, &prev->submit,
|
|
|
|
&request->submitq);
|
2016-11-15 04:41:02 +08:00
|
|
|
if (engine->schedule)
|
2018-04-19 02:40:51 +08:00
|
|
|
__i915_sched_node_add_dependency(&request->sched,
|
|
|
|
&prev->sched,
|
|
|
|
&request->dep,
|
|
|
|
0);
|
2016-11-15 04:41:02 +08:00
|
|
|
}
|
2016-09-09 21:12:00 +08:00
|
|
|
|
2016-10-28 20:58:58 +08:00
|
|
|
spin_lock_irq(&timeline->lock);
|
2016-10-28 20:58:57 +08:00
|
|
|
list_add_tail(&request->link, &timeline->requests);
|
2016-10-28 20:58:58 +08:00
|
|
|
spin_unlock_irq(&timeline->lock);
|
|
|
|
|
2017-02-23 15:44:08 +08:00
|
|
|
GEM_BUG_ON(timeline->seqno != request->fence.seqno);
|
2016-10-28 20:58:46 +08:00
|
|
|
i915_gem_active_set(&timeline->last_request, request);
|
2016-10-28 20:58:57 +08:00
|
|
|
|
2016-09-09 21:11:55 +08:00
|
|
|
list_add_tail(&request->ring_link, &ring->request_list);
|
2018-05-24 16:11:35 +08:00
|
|
|
if (list_is_first(&request->ring_link, &ring->request_list)) {
|
|
|
|
GEM_TRACE("marking %s as active\n", ring->timeline->name);
|
2018-04-30 21:15:03 +08:00
|
|
|
list_add(&ring->active_link, &request->i915->gt.active_rings);
|
2018-05-24 16:11:35 +08:00
|
|
|
}
|
2016-10-28 20:58:57 +08:00
|
|
|
request->emitted_jiffies = jiffies;
|
2016-09-09 21:11:55 +08:00
|
|
|
|
2018-02-07 16:43:50 +08:00
|
|
|
/*
|
|
|
|
* Let the backend know a new request has arrived that may need
|
2016-11-15 04:41:01 +08:00
|
|
|
* to adjust the existing execution schedule due to a high priority
|
|
|
|
* request - i.e. we may want to preempt the current request in order
|
|
|
|
* to run a high priority dependency chain *before* we can execute this
|
|
|
|
* request.
|
|
|
|
*
|
|
|
|
* This is called before the request is ready to run so that we can
|
|
|
|
* decide whether to preempt the entire chain so that it is ready to
|
|
|
|
* run at the earliest possible convenience.
|
|
|
|
*/
|
2018-05-07 21:57:26 +08:00
|
|
|
local_bh_disable();
|
|
|
|
rcu_read_lock(); /* RCU serialisation for set-wedged protection */
|
2018-10-01 22:47:53 +08:00
|
|
|
if (engine->schedule) {
|
|
|
|
struct i915_sched_attr attr = request->gem_context->sched;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Boost priorities to new clients (new request flows).
|
|
|
|
*
|
|
|
|
* Allow interactive/synchronous clients to jump ahead of
|
|
|
|
* the bulk clients. (FQ_CODEL)
|
|
|
|
*/
|
|
|
|
if (!prev || i915_request_completed(prev))
|
|
|
|
attr.priority |= I915_PRIORITY_NEWCLIENT;
|
|
|
|
|
|
|
|
engine->schedule(request, &attr);
|
|
|
|
}
|
2018-03-07 21:42:25 +08:00
|
|
|
rcu_read_unlock();
|
2016-09-09 21:11:54 +08:00
|
|
|
i915_sw_fence_commit(&request->submit);
|
|
|
|
local_bh_enable(); /* Kick the execlists tasklet if just scheduled */
|
2018-02-07 16:43:49 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* In typical scenarios, we do not expect the previous request on
|
|
|
|
* the timeline to be still tracked by timeline->last_request if it
|
|
|
|
* has been completed. If the completed request is still here, that
|
|
|
|
* implies that request retirement is a long way behind submission,
|
|
|
|
* suggesting that we haven't been retiring frequently enough from
|
|
|
|
* the combination of retire-before-alloc, waiters and the background
|
|
|
|
* retirement worker. So if the last request on this timeline was
|
|
|
|
* already completed, do a catch up pass, flushing the retirement queue
|
|
|
|
* up to this client. Since we have now moved the heaviest operations
|
|
|
|
* during retirement onto secondary workers, such as freeing objects
|
|
|
|
* or contexts, retiring a bunch of requests is mostly list management
|
|
|
|
* (and cache misses), and so we should not be overly penalizing this
|
|
|
|
* client by performing excess work, though we may still performing
|
|
|
|
* work on behalf of others -- but instead we should benefit from
|
|
|
|
* improved resource management. (Well, that's the theory at least.)
|
|
|
|
*/
|
2018-02-21 17:56:36 +08:00
|
|
|
if (prev && i915_request_completed(prev))
|
|
|
|
i915_request_retire_upto(prev);
|
2016-07-20 16:21:08 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static unsigned long local_clock_us(unsigned int *cpu)
|
|
|
|
{
|
|
|
|
unsigned long t;
|
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
/*
|
|
|
|
* Cheaply and approximately convert from nanoseconds to microseconds.
|
2016-07-20 16:21:08 +08:00
|
|
|
* The result and subsequent calculations are also defined in the same
|
|
|
|
* approximate microseconds units. The principal source of timing
|
|
|
|
* error here is from the simple truncation.
|
|
|
|
*
|
|
|
|
* Note that local_clock() is only defined wrt to the current CPU;
|
|
|
|
* the comparisons are no longer valid if we switch CPUs. Instead of
|
|
|
|
* blocking preemption for the entire busywait, we can detect the CPU
|
|
|
|
* switch and use that as indicator of system load and a reason to
|
|
|
|
* stop busywaiting, see busywait_stop().
|
|
|
|
*/
|
|
|
|
*cpu = get_cpu();
|
|
|
|
t = local_clock() >> 10;
|
|
|
|
put_cpu();
|
|
|
|
|
|
|
|
return t;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool busywait_stop(unsigned long timeout, unsigned int cpu)
|
|
|
|
{
|
|
|
|
unsigned int this_cpu;
|
|
|
|
|
|
|
|
if (time_after(local_clock_us(&this_cpu), timeout))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return this_cpu != cpu;
|
|
|
|
}
|
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
static bool __i915_spin_request(const struct i915_request *rq,
|
2017-09-22 20:03:33 +08:00
|
|
|
u32 seqno, int state, unsigned long timeout_us)
|
2016-07-20 16:21:08 +08:00
|
|
|
{
|
2018-02-21 17:56:36 +08:00
|
|
|
struct intel_engine_cs *engine = rq->engine;
|
2017-02-17 23:13:01 +08:00
|
|
|
unsigned int irq, cpu;
|
2016-07-20 16:21:08 +08:00
|
|
|
|
2017-09-22 20:03:33 +08:00
|
|
|
GEM_BUG_ON(!seqno);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Only wait for the request if we know it is likely to complete.
|
|
|
|
*
|
|
|
|
* We don't track the timestamps around requests, nor the average
|
|
|
|
* request length, so we do not have a good indicator that this
|
|
|
|
* request will complete within the timeout. What we do know is the
|
|
|
|
* order in which requests are executed by the engine and so we can
|
|
|
|
* tell if the request has started. If the request hasn't started yet,
|
|
|
|
* it is a fair assumption that it will not complete within our
|
|
|
|
* relatively short timeout.
|
|
|
|
*/
|
2018-08-06 19:26:05 +08:00
|
|
|
if (!intel_engine_has_started(engine, seqno))
|
2017-09-22 20:03:33 +08:00
|
|
|
return false;
|
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
/*
|
|
|
|
* When waiting for high frequency requests, e.g. during synchronous
|
2016-07-20 16:21:08 +08:00
|
|
|
* rendering split between the CPU and GPU, the finite amount of time
|
|
|
|
* required to set up the irq and wait upon it limits the response
|
|
|
|
* rate. By busywaiting on the request completion for a short while we
|
|
|
|
* can service the high frequency waits as quick as possible. However,
|
|
|
|
* if it is a slow request, we want to sleep as quickly as possible.
|
|
|
|
* The tradeoff between waiting and sleeping is roughly the time it
|
|
|
|
* takes to sleep on a request, on the order of a microsecond.
|
|
|
|
*/
|
|
|
|
|
2018-06-28 04:13:03 +08:00
|
|
|
irq = READ_ONCE(engine->breadcrumbs.irq_count);
|
2016-07-20 16:21:08 +08:00
|
|
|
timeout_us += local_clock_us(&cpu);
|
|
|
|
do {
|
2018-08-06 19:26:05 +08:00
|
|
|
if (intel_engine_has_completed(engine, seqno))
|
2018-02-21 17:56:36 +08:00
|
|
|
return seqno == i915_request_global_seqno(rq);
|
2016-07-20 16:21:08 +08:00
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
/*
|
|
|
|
* Seqno are meant to be ordered *before* the interrupt. If
|
2017-02-17 23:13:01 +08:00
|
|
|
* we see an interrupt without a corresponding seqno advance,
|
|
|
|
* assume we won't see one in the near future but require
|
|
|
|
* the engine->seqno_barrier() to fixup coherency.
|
|
|
|
*/
|
2018-06-28 04:13:03 +08:00
|
|
|
if (READ_ONCE(engine->breadcrumbs.irq_count) != irq)
|
2017-02-17 23:13:01 +08:00
|
|
|
break;
|
|
|
|
|
2016-07-20 16:21:08 +08:00
|
|
|
if (signal_pending_state(state, current))
|
|
|
|
break;
|
|
|
|
|
|
|
|
if (busywait_stop(timeout_us, cpu))
|
|
|
|
break;
|
|
|
|
|
2016-10-25 17:03:14 +08:00
|
|
|
cpu_relax();
|
2016-07-20 16:21:08 +08:00
|
|
|
} while (!need_resched());
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
static bool __i915_wait_request_check_and_reset(struct i915_request *request)
|
2016-10-28 20:58:48 +08:00
|
|
|
{
|
2018-04-07 06:03:54 +08:00
|
|
|
struct i915_gpu_error *error = &request->i915->gpu_error;
|
|
|
|
|
|
|
|
if (likely(!i915_reset_handoff(error)))
|
2017-02-23 15:44:20 +08:00
|
|
|
return false;
|
2016-10-28 20:58:48 +08:00
|
|
|
|
2017-02-23 15:44:20 +08:00
|
|
|
__set_current_state(TASK_RUNNING);
|
2018-04-07 06:03:54 +08:00
|
|
|
i915_reset(request->i915, error->stalled_mask, error->reason);
|
2017-02-23 15:44:20 +08:00
|
|
|
return true;
|
2016-10-28 20:58:48 +08:00
|
|
|
}
|
|
|
|
|
2016-07-20 16:21:08 +08:00
|
|
|
/**
|
2018-02-23 01:24:05 +08:00
|
|
|
* i915_request_wait - wait until execution of request has finished
|
2018-02-21 17:56:36 +08:00
|
|
|
* @rq: the request to wait upon
|
2016-09-09 21:11:49 +08:00
|
|
|
* @flags: how to wait
|
2016-10-28 20:58:27 +08:00
|
|
|
* @timeout: how long to wait in jiffies
|
|
|
|
*
|
2018-02-23 01:24:05 +08:00
|
|
|
* i915_request_wait() waits for the request to be completed, for a
|
2016-10-28 20:58:27 +08:00
|
|
|
* maximum of @timeout jiffies (with MAX_SCHEDULE_TIMEOUT implying an
|
|
|
|
* unbounded wait).
|
2016-07-20 16:21:08 +08:00
|
|
|
*
|
2016-10-28 20:58:27 +08:00
|
|
|
* If the caller holds the struct_mutex, the caller must pass I915_WAIT_LOCKED
|
|
|
|
* in via the flags, and vice versa if the struct_mutex is not held, the caller
|
|
|
|
* must not specify that the wait is locked.
|
2016-07-20 16:21:08 +08:00
|
|
|
*
|
2016-10-28 20:58:27 +08:00
|
|
|
* Returns the remaining time (in jiffies) if the request completed, which may
|
|
|
|
* be zero or -ETIME if the request is unfinished after the timeout expires.
|
|
|
|
* May return -EINTR is called with I915_WAIT_INTERRUPTIBLE and a signal is
|
|
|
|
* pending before the request completes.
|
2016-07-20 16:21:08 +08:00
|
|
|
*/
|
2018-02-21 17:56:36 +08:00
|
|
|
long i915_request_wait(struct i915_request *rq,
|
2016-10-28 20:58:27 +08:00
|
|
|
unsigned int flags,
|
|
|
|
long timeout)
|
2016-07-20 16:21:08 +08:00
|
|
|
{
|
2016-09-09 21:11:49 +08:00
|
|
|
const int state = flags & I915_WAIT_INTERRUPTIBLE ?
|
|
|
|
TASK_INTERRUPTIBLE : TASK_UNINTERRUPTIBLE;
|
2018-02-21 17:56:36 +08:00
|
|
|
wait_queue_head_t *errq = &rq->i915->gpu_error.wait_queue;
|
2017-02-23 15:44:19 +08:00
|
|
|
DEFINE_WAIT_FUNC(reset, default_wake_function);
|
|
|
|
DEFINE_WAIT_FUNC(exec, default_wake_function);
|
2016-07-20 16:21:08 +08:00
|
|
|
struct intel_wait wait;
|
|
|
|
|
|
|
|
might_sleep();
|
2016-09-09 21:11:50 +08:00
|
|
|
#if IS_ENABLED(CONFIG_LOCKDEP)
|
2016-10-28 20:58:27 +08:00
|
|
|
GEM_BUG_ON(debug_locks &&
|
2018-02-21 17:56:36 +08:00
|
|
|
!!lockdep_is_held(&rq->i915->drm.struct_mutex) !=
|
2016-09-09 21:11:50 +08:00
|
|
|
!!(flags & I915_WAIT_LOCKED));
|
|
|
|
#endif
|
2016-10-28 20:58:27 +08:00
|
|
|
GEM_BUG_ON(timeout < 0);
|
2016-07-20 16:21:08 +08:00
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
if (i915_request_completed(rq))
|
2016-10-28 20:58:27 +08:00
|
|
|
return timeout;
|
2016-07-20 16:21:08 +08:00
|
|
|
|
2016-10-28 20:58:27 +08:00
|
|
|
if (!timeout)
|
|
|
|
return -ETIME;
|
2016-07-20 16:21:08 +08:00
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
trace_i915_request_wait_begin(rq, flags);
|
2016-07-20 16:21:08 +08:00
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
add_wait_queue(&rq->execute, &exec);
|
2017-02-23 15:44:11 +08:00
|
|
|
if (flags & I915_WAIT_LOCKED)
|
|
|
|
add_wait_queue(errq, &reset);
|
|
|
|
|
2018-06-28 04:13:04 +08:00
|
|
|
intel_wait_init(&wait);
|
2018-10-01 22:47:55 +08:00
|
|
|
if (flags & I915_WAIT_PRIORITY)
|
|
|
|
i915_schedule_bump_priority(rq, I915_PRIORITY_WAIT);
|
2017-02-23 15:44:14 +08:00
|
|
|
|
2017-02-23 15:44:17 +08:00
|
|
|
restart:
|
2017-02-23 15:44:22 +08:00
|
|
|
do {
|
|
|
|
set_current_state(state);
|
2018-02-21 17:56:36 +08:00
|
|
|
if (intel_wait_update_request(&wait, rq))
|
2017-02-23 15:44:22 +08:00
|
|
|
break;
|
2017-02-23 15:44:12 +08:00
|
|
|
|
2017-02-23 15:44:22 +08:00
|
|
|
if (flags & I915_WAIT_LOCKED &&
|
2018-02-21 17:56:36 +08:00
|
|
|
__i915_wait_request_check_and_reset(rq))
|
2017-02-23 15:44:22 +08:00
|
|
|
continue;
|
2016-07-20 16:21:08 +08:00
|
|
|
|
2017-02-23 15:44:22 +08:00
|
|
|
if (signal_pending_state(state, current)) {
|
|
|
|
timeout = -ERESTARTSYS;
|
2016-10-28 20:58:48 +08:00
|
|
|
goto complete;
|
2017-02-23 15:44:22 +08:00
|
|
|
}
|
2016-10-28 20:58:48 +08:00
|
|
|
|
2017-02-23 15:44:22 +08:00
|
|
|
if (!timeout) {
|
|
|
|
timeout = -ETIME;
|
|
|
|
goto complete;
|
|
|
|
}
|
2017-02-23 15:44:12 +08:00
|
|
|
|
2017-02-23 15:44:22 +08:00
|
|
|
timeout = io_schedule_timeout(timeout);
|
|
|
|
} while (1);
|
2016-10-28 20:58:48 +08:00
|
|
|
|
2017-02-23 15:44:22 +08:00
|
|
|
GEM_BUG_ON(!intel_wait_has_seqno(&wait));
|
2018-02-21 17:56:36 +08:00
|
|
|
GEM_BUG_ON(!i915_sw_fence_signaled(&rq->submit));
|
2016-10-28 20:58:48 +08:00
|
|
|
|
2016-08-06 00:11:24 +08:00
|
|
|
/* Optimistic short spin before touching IRQs */
|
2018-02-21 17:56:36 +08:00
|
|
|
if (__i915_spin_request(rq, wait.seqno, state, 5))
|
2016-07-20 16:21:08 +08:00
|
|
|
goto complete;
|
|
|
|
|
|
|
|
set_current_state(state);
|
2018-02-21 17:56:36 +08:00
|
|
|
if (intel_engine_add_wait(rq->engine, &wait))
|
|
|
|
/*
|
|
|
|
* In order to check that we haven't missed the interrupt
|
2016-07-20 16:21:08 +08:00
|
|
|
* as we enabled it, we need to kick ourselves to do a
|
|
|
|
* coherent check on the seqno before we sleep.
|
|
|
|
*/
|
|
|
|
goto wakeup;
|
|
|
|
|
2017-02-23 15:44:21 +08:00
|
|
|
if (flags & I915_WAIT_LOCKED)
|
2018-02-21 17:56:36 +08:00
|
|
|
__i915_wait_request_check_and_reset(rq);
|
2017-02-23 15:44:21 +08:00
|
|
|
|
2016-07-20 16:21:08 +08:00
|
|
|
for (;;) {
|
|
|
|
if (signal_pending_state(state, current)) {
|
2016-10-28 20:58:27 +08:00
|
|
|
timeout = -ERESTARTSYS;
|
2016-07-20 16:21:08 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2016-10-28 20:58:27 +08:00
|
|
|
if (!timeout) {
|
|
|
|
timeout = -ETIME;
|
2016-07-20 16:21:08 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2016-10-28 20:58:27 +08:00
|
|
|
timeout = io_schedule_timeout(timeout);
|
|
|
|
|
2017-02-23 15:44:14 +08:00
|
|
|
if (intel_wait_complete(&wait) &&
|
2018-02-21 17:56:36 +08:00
|
|
|
intel_wait_check_request(&wait, rq))
|
2016-07-20 16:21:08 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
set_current_state(state);
|
|
|
|
|
|
|
|
wakeup:
|
2018-02-21 17:56:36 +08:00
|
|
|
/*
|
|
|
|
* Carefully check if the request is complete, giving time
|
2016-07-20 16:21:08 +08:00
|
|
|
* for the seqno to be visible following the interrupt.
|
|
|
|
* We also have to check in case we are kicked by the GPU
|
|
|
|
* reset in order to drop the struct_mutex.
|
|
|
|
*/
|
2018-02-21 17:56:36 +08:00
|
|
|
if (__i915_request_irq_complete(rq))
|
2016-07-20 16:21:08 +08:00
|
|
|
break;
|
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
/*
|
|
|
|
* If the GPU is hung, and we hold the lock, reset the GPU
|
2016-09-09 21:11:51 +08:00
|
|
|
* and then check for completion. On a full reset, the engine's
|
|
|
|
* HW seqno will be advanced passed us and we are complete.
|
|
|
|
* If we do a partial reset, we have to wait for the GPU to
|
|
|
|
* resume and update the breadcrumb.
|
|
|
|
*
|
|
|
|
* If we don't hold the mutex, we can just wait for the worker
|
|
|
|
* to come along and update the breadcrumb (either directly
|
|
|
|
* itself, or indirectly by recovering the GPU).
|
|
|
|
*/
|
|
|
|
if (flags & I915_WAIT_LOCKED &&
|
2018-02-21 17:56:36 +08:00
|
|
|
__i915_wait_request_check_and_reset(rq))
|
2016-09-09 21:11:51 +08:00
|
|
|
continue;
|
|
|
|
|
2016-07-20 16:21:08 +08:00
|
|
|
/* Only spin if we know the GPU is processing this request */
|
2018-02-21 17:56:36 +08:00
|
|
|
if (__i915_spin_request(rq, wait.seqno, state, 2))
|
2016-07-20 16:21:08 +08:00
|
|
|
break;
|
2017-02-23 15:44:17 +08:00
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
if (!intel_wait_check_request(&wait, rq)) {
|
|
|
|
intel_engine_remove_wait(rq->engine, &wait);
|
2017-02-23 15:44:17 +08:00
|
|
|
goto restart;
|
|
|
|
}
|
2016-07-20 16:21:08 +08:00
|
|
|
}
|
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
intel_engine_remove_wait(rq->engine, &wait);
|
2016-07-20 16:21:08 +08:00
|
|
|
complete:
|
2017-02-23 15:44:19 +08:00
|
|
|
__set_current_state(TASK_RUNNING);
|
2017-02-23 15:44:11 +08:00
|
|
|
if (flags & I915_WAIT_LOCKED)
|
|
|
|
remove_wait_queue(errq, &reset);
|
2018-02-21 17:56:36 +08:00
|
|
|
remove_wait_queue(&rq->execute, &exec);
|
|
|
|
trace_i915_request_wait_end(rq);
|
2016-07-20 16:21:08 +08:00
|
|
|
|
2016-10-28 20:58:27 +08:00
|
|
|
return timeout;
|
2016-07-20 16:21:08 +08:00
|
|
|
}
|
2016-08-04 14:52:42 +08:00
|
|
|
|
2018-04-30 21:15:02 +08:00
|
|
|
static void ring_retire_requests(struct intel_ring *ring)
|
2016-08-04 14:52:42 +08:00
|
|
|
{
|
2018-02-21 17:56:36 +08:00
|
|
|
struct i915_request *request, *next;
|
2016-08-04 14:52:42 +08:00
|
|
|
|
2016-10-28 20:58:46 +08:00
|
|
|
list_for_each_entry_safe(request, next,
|
2018-04-30 21:15:02 +08:00
|
|
|
&ring->request_list, ring_link) {
|
|
|
|
if (!i915_request_completed(request))
|
2017-02-23 15:44:14 +08:00
|
|
|
break;
|
2016-08-04 14:52:42 +08:00
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
i915_request_retire(request);
|
2018-04-30 21:15:02 +08:00
|
|
|
}
|
2016-08-04 14:52:42 +08:00
|
|
|
}
|
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
void i915_retire_requests(struct drm_i915_private *i915)
|
2016-08-04 14:52:42 +08:00
|
|
|
{
|
2018-04-30 21:15:03 +08:00
|
|
|
struct intel_ring *ring, *tmp;
|
2016-08-04 14:52:42 +08:00
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
lockdep_assert_held(&i915->drm.struct_mutex);
|
2016-08-04 14:52:42 +08:00
|
|
|
|
2018-02-21 17:56:36 +08:00
|
|
|
if (!i915->gt.active_requests)
|
2016-08-04 14:52:42 +08:00
|
|
|
return;
|
|
|
|
|
2018-04-30 21:15:03 +08:00
|
|
|
list_for_each_entry_safe(ring, tmp, &i915->gt.active_rings, active_link)
|
2018-04-30 21:15:02 +08:00
|
|
|
ring_retire_requests(ring);
|
2016-08-04 14:52:42 +08:00
|
|
|
}
|
2017-02-14 01:15:21 +08:00
|
|
|
|
|
|
|
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
|
|
|
|
#include "selftests/mock_request.c"
|
2018-02-21 17:56:36 +08:00
|
|
|
#include "selftests/i915_request.c"
|
2017-02-14 01:15:21 +08:00
|
|
|
#endif
|