[Intel-gfx] [PATCH 07/23] drm/i915: Switch to object allocations for page directories

[Tvrtko Ursulin]

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