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@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
