Re: [PATCH 3/6] drm/i915: Split the batch pool by engine

[Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>]

On 03/19/2015 10:06 AM, Chris Wilson wrote:
> On Thu, Mar 19, 2015 at 09:36:14AM +0000, Tvrtko Ursulin wrote:
>> Oh right, I got it, but not sure I like it that much. I don't think
>> batch pool implementation is well enough decoupled from the users.
>
> "batch pool" Splitting it this way actually improves decoupling.

Of the resulting system yes, of the actual modules no in my opinion.

>> Well in a way at least where when we talk about LRU ordering, it
>> depends on retiring working properly and that is not obvious from
>> code layout and module separation.
>
> I've lost you. The list is in LRU submission order. With this split, the
> list is both in LRU submission and LRU retirememnt order. That the two
> are not the same originally is not a fault of retiring not working
> properly, but that the hardware is split into different units and
> timelines.
>
>> And then with this me move traversal inefficiency to possible more
>> resource use. Would it be better to fix the cause rather than
>> symptoms? Is it feasible? What would be the downside of retiring all
>> rings before submission?
>
> Not really. Inefficient userspace is inefficient. All we want to be sure
> is that one abusive client doesn't cause a DoS on another, whilst making
> sure that good clients are not penalized.

Not sure to which of my question your "not really" was the answer.

I understood that this is about the completed work which hasn't been 
retired due the latter only happening on submission to the same ring, or 
with too low frequency from retire work handler.

If this is true, could we just not do a retire pass on all rings on any 
submission?

Otherwise, how do per ring pools help abusive and good client on the 
same ring?

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx