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 <chris@xxxxxxxxxxxxxxxxxx> > > Cc: Christian König <christian.koenig@xxxxxxx> > > Cc: Michel Dänzer <michel.daenzer@xxxxxxx> > > Reviewed-by: Christian König <christian.koenig@xxxxxxx> > > 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
