[Intel-gfx] [PATCH 08/12] drm/i915: Split execlist priority queue into rbtree + linked list

[Chris Wilson]

On Mon, May 15, 2017 at 12:45:16PM +0100, Tvrtko Ursulin wrote:
> 
> On 11/05/2017 20:59, Chris Wilson wrote:
> >+	if (prio == I915_PRIORITY_NORMAL) {
> >+		p = &engine->default_priolist;
> >+	} else {
> >+		p = kmalloc(sizeof(*p), GFP_ATOMIC);
> 
> I am back to being nervous about this.
> 
> I don't see that even with a dedicated slab we can control the
> number of spare objects kept around and also cannot turn off the
> merging. If only there was something like SLAB_NO_MERGE and
> kmem_cache_preallocate(cache, n). With that we would be able to keep
> some amount of ready objects in the cache.
> 
> As an alternative I was thinking about how hard would it be to keep
> the priority levels around even when lists become empty? And only
> prune from the shrinker perhaps? Or from the idle worker if we get
> to some larger number of priority levels.

Having a number preallocated, or keeping a freelist (which I'd prefer
using the slab cache for then writing our own) of priolist cannot
guarantee that this allocation will succeed. I'm still contemplating
that we may use a full u32 range, and we are back to just using an
rbtree inside the priotree instead of levels.

Reduce to a list inside a level is still a very useful simplification
for unwind that I think we want to persevere. As far as rendering
out-of-order following an oom, I'm not that concerned about -- we may
hang the gpu in the middle of a swap storm, worst case.

Ok, Michal is right. If we permanently fallback to 0 after a failure,
ordering is correct. We can then recover to multiple levels on idle.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre