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

[Tvrtko Ursulin]

On 05/05/2017 14:51, Chris Wilson wrote:
> On Fri, May 05, 2017 at 02:37:41PM +0100, Tvrtko Ursulin wrote:
>>
>> On 05/05/2017 14:32, Chris Wilson wrote:
>>> On Fri, May 05, 2017 at 02:19:07PM +0100, Tvrtko Ursulin wrote:
>>>>
>>>> On 03/05/2017 12:37, Chris Wilson wrote:
>>>>> struct intel_engine_cs {
>>>>> @@ -367,6 +373,7 @@ struct intel_engine_cs {
>>>>>
>>>>> 	/* Execlists */
>>>>> 	struct tasklet_struct irq_tasklet;
>>>>> +	struct execlist_priolist default_priolist;
>>>>> 	struct execlist_port {
>>>>> 		struct drm_i915_gem_request *request_count;
>>>>> #define EXECLIST_COUNT_BITS 2
>>>>>
>>>
>>> Just a small bikeshed to consider. Having switched to
>>> I915_PRIORITY_NORMAL, do we have a better name for default_priolist? I
>>> still prefer default_priolist over normal_priolist. Go back to
>>> I915_PRIORITY_DEFAULT?
>>
>> default_priolist is fine I think since it is dual purpose. Primary
>> purpose to avoid allocations as you said.
>>
>> Although I am still a bit dejected how some userspace could decide
>> one day to send everything at I915_PRIORITY_NORMAL - n, in order to
>> use I915_PRIORITY_NORMAL as the high prio not requiring
>> cap_sys_admin, and in doing so completely defeat the atomic kmalloc
>> avoidance. :(
>
> Should we just bite the bullet and install a kmem_cache here?
> It didn't solve the kmalloc error handling, but it does at least give us
> a freelist. There is a reasonable argument that as soon as userspace
> starts using non-default priorities, we may see many different levels
> justifying allocating a whole slab upfront.

Actually my argument is pants since allocations only happen with 
"opening" a new priority level. So I think leave it as it is until there 
is a need.

Regards,

Tvrtko