[PATCH 1/2] dma-buf: Expand reservation_list to fill allocation

Chris Wilson chris at chris-wilson.co.uk
Mon Jul 15 10:58:42 UTC 2019


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 at chris-wilson.co.uk>
> > Cc: Christian König <christian.koenig at amd.com>
> > Cc: Michel Dänzer <michel.daenzer at amd.com>
> 
> Reviewed-by: Christian König <christian.koenig at 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


More information about the dri-devel mailing list