On 03/07/2020 10:00, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-07-03 09:44:52)
On 02/07/2020 09:32, Chris Wilson wrote:
The GEM object is grossly overweight for the practicality of tracking
large numbers of individual pages, yet it is currently our only
abstraction for tracking DMA allocations. Since those allocations need
to be reserved upfront before an operation, and that we need to break
away from simple system memory, we need to ditch using plain struct page
wrappers.
[Calling all page table experts...] :)
So.. mostly 4k allocations via GEM objects? Sounds not ideal on first.
What is the relationship between object size and number of 4k objects
needed for page tables?
Reminder on why we need to break away from simple system memory?
The page tables are stored in device memory, which at the moment are
plain pages with dma mappings.
Need to
have a list of GEM objects which can be locked in the ww locking phase?
Yes, since we will need to be able to reserve all the device memory we
need for execution.
But how do you allocate these objects up front, when allocation needs to
be under the ww lock in case evictions need to be triggered.
By preeallocating enough objects to cover the page directories during
the reservation phase. The previous patch moved the allocations from the
point-of-use to before we insert the vma. Having made it the onus of the
caller to provide the page directories allocations, we can then do it
early on during the memory reservations.
Okay I missed the importance of the previous patch.
But preallocations have to be able to trigger evictions. Is the
preallocating objects split then into creating objects and obtaining
backing store? I do not see this in this patch, alloc_pt_dma both
creates the object and pins the pages.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx