On Thu, Mar 19, 2015 at 11:39:16AM +0000, Tvrtko Ursulin wrote: > On 03/19/2015 10:06 AM, Chris Wilson wrote: > >On Thu, Mar 19, 2015 at 09:36:14AM +0000, Tvrtko Ursulin wrote: > >>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. We do "fix" the cause later, and I've amended the throttling in mesa to prevent a reoccurrence. So I was thinking of why we only retire on the current ring. > 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? No. The problem is that rings retire out of order. So a global LRU submission list is not strictly separated between inactive and active objects (in contrast to the per-engine list where it is true). -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
