[PATCH 6/7] drm/i915/ttm, drm/ttm: Introduce a TTM i915 gem object backend

[Thomas Hellström]

On 5/11/21 4:09 PM, Christian König wrote:
>
>
> Am 11.05.21 um 16:06 schrieb Thomas Hellström (Intel):
>>
>> On 5/11/21 3:58 PM, Christian König wrote:
>>> Am 11.05.21 um 15:25 schrieb Thomas Hellström:
>>>> Most logical place to introduce TTM buffer objects is as an i915
>>>> gem object backend. We need to add some ops to account for added
>>>> functionality like delayed delete and LRU list manipulation.
>>>>
>>>> Initially we support only LMEM and SYSTEM memory, but SYSTEM
>>>> (which in this case means evicted LMEM objects) is not
>>>> visible to i915 GEM yet. The plan is to move the i915 gem system 
>>>> region
>>>> over to the TTM system memory type in upcoming patches.
>>>>
>>>> We set up GPU bindings directly both from LMEM and from the system 
>>>> region,
>>>> as there is no need to use the legacy TTM_TT memory type. We reserve
>>>> that for future porting of GGTT bindings to TTM.
>>>>
>>>> There are some changes to TTM to allow for purging system memory 
>>>> buffer
>>>> objects and to refuse swapping of some objects: Unfortunately i915 gem
>>>> still relies heavily on short-term object pinning, and we've chosen to
>>>> keep short-term-pinned buffer objects on the TTM LRU lists for now,
>>>> meaning that we need some sort of mechanism to tell TTM they are not
>>>> swappable. A longer term goal is to get rid of the short-term pinning.
>>>
>>> Well just use the eviction_valuable interface for this.
>>
>> Yes, we do that for vram/lmem eviction, but we have nothing similar 
>> for system swapping. Do I understand you correctly that you want me 
>> to add a call to eviction_valuable() also for that instead of 
>> swap_possible()?
>
> You should already have that. eviction_valuable is called in both cases.
>
Hmm. I can only see it called from ttm_mem_evict_first() which is not in 
the swapping path? Or do I miss something?

Thanks,

Thomas