b1e3177bd1
Forgo the struct_mutex serialisation for i915_active, and interpose its own mutex handling for active/retire. This is a multi-layered sleight-of-hand. First, we had to ensure that no active/retire callbacks accidentally inverted the mutex ordering rules, nor assumed that they were themselves serialised by struct_mutex. More challenging though, is the rule over updating elements of the active rbtree. Instead of the whole i915_active now being serialised by struct_mutex, allocations/rotations of the tree are serialised by the i915_active.mutex and individual nodes are serialised by the caller using the i915_timeline.mutex (we need to use nested spinlocks to interact with the dma_fence callback lists). The pain point here is that instead of a single mutex around execbuf, we now have to take a mutex for active tracker (one for each vma, context, etc) and a couple of spinlocks for each fence update. The improvement in fine grained locking allowing for multiple concurrent clients (eventually!) should be worth it in typical loads. v2: Add some comments that barely elucidate anything :( Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191004134015.13204-6-chris@chris-wilson.co.uk
29 lines
585 B
C
29 lines
585 B
C
/*
|
|
* SPDX-License-Identifier: MIT
|
|
*
|
|
* Copyright © 2017-2018 Intel Corporation
|
|
*/
|
|
|
|
#include "../intel_timeline.h"
|
|
|
|
#include "mock_timeline.h"
|
|
|
|
void mock_timeline_init(struct intel_timeline *timeline, u64 context)
|
|
{
|
|
timeline->gt = NULL;
|
|
timeline->fence_context = context;
|
|
|
|
mutex_init(&timeline->mutex);
|
|
|
|
INIT_ACTIVE_FENCE(&timeline->last_request, &timeline->mutex);
|
|
INIT_LIST_HEAD(&timeline->requests);
|
|
|
|
i915_syncmap_init(&timeline->sync);
|
|
|
|
INIT_LIST_HEAD(&timeline->link);
|
|
}
|
|
|
|
void mock_timeline_fini(struct intel_timeline *timeline)
|
|
{
|
|
i915_syncmap_free(&timeline->sync);
|
|
}
|