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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
