Quoting Koenig, Christian (2019-07-14 08:37:47) > Am 12.07.19 um 10:03 schrieb Chris Wilson: > > Since kmalloc() will round up the allocation to the next slab size or > > page, it will normally return a pointer to a memory block bigger than we > > asked for. We can query for the actual size of the allocated block using > > ksize() and expand our variable size reservation_list to take advantage > > of that extra space. > > > > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> > > Cc: Christian König <christian.koe...@amd.com> > > Cc: Michel Dänzer <michel.daen...@amd.com> > > Reviewed-by: Christian König <christian.koe...@amd.com> > > BTW: I was wondering if we shouldn't replace the reservation_object_list > with a dma_fence_chain.
I thought the dma_fence_chain tracked points (naturally ordered) along a singe timeline, whereas the reservation list tracked parallel timelines. Seems like a semantic mismatch? (Making lookup slower would not be pleasant, tbh, both waiting on and updating are an issue with the severe amount of reservation_objects we currently process per execbuf.) -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
