[PATCH 4/5] drm/amdgpu: Set/clear CPU_ACCESS_REQUIRED flag on page fault and CS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 29/06/17 08:26 AM, John Brooks wrote:
> On Wed, Jun 28, 2017 at 03:05:32PM +0200, Christian König wrote:
>> Am 28.06.2017 um 04:33 schrieb John Brooks:
>>> When the AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED flag is given by userspace,
>>> it should only be treated as a hint to initially place a BO somewhere CPU
>>> accessible, rather than having a permanent effect on BO placement.
>>>
>>> Instead of the flag being set in stone at BO creation, set the flag when a
>>> page fault occurs so that it goes somewhere CPU-visible, and clear it when
>>> the BO is requested by the GPU.
>>>
>>> However, clearing the CPU_ACCESS_REQUIRED flag may move BOs in GTT to
>>> invisible VRAM, where they may promptly generate another page fault. When
>>> BOs are constantly moved back and forth like this, it is highly detrimental
>>> to performance. Only clear the flag on CS if:
>>>
>>> - The BO wasn't page faulted for a certain amount of time (currently 10
>>>   seconds), and
>>> - its last page fault didn't occur too soon (currently 500ms) after its
>>>   last CS request, or vice versa.
>>>
>>> Setting the flag in amdgpu_fault_reserve_notify() also means that we can
>>> remove the loop to restrict lpfn to the end of visible VRAM, because
>>> amdgpu_ttm_placement_init() will do it for us.
>>
>> I'm fine with the general approach, but I'm still absolutely not keen about
>> clearing the flag when userspace has originally specified it.

Is there any specific concern you have about that?


>> Please add a new flag something like AMDGPU_GEM_CREATE_CPU_ACCESS_HINT or
>> something like this.
> 
> Is it the fact that we clear a flag that userspace expects not to have changed
> if it queries it later? I think that's the only effect of this that's directly
> visible to userspace code.

I don't see any way for userspace to query that.


> As for a new "hint" flag, I assume this new flag would be an alternative to the
> existing CPU_ACCESS_REQUIRED flag, and we'd change Mesa et al to use it in
> situations where the kernel *should* place a BO somewhere CPU-accessible, but
> is permitted to move it elsewhere. Is that correct?

That seems silly. The userspace flag could never be more than a hint.
Unfortunately we named it to suggest differently, but we have to live
with that.

If we do need a new hint flag internally in the driver, we should simply
translate AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED to the new flag in
amdgpu_gem_create_ioctl, and not expose the new flag to userspace.


But other than the question in my followup to the cover letter, this
patch looks good to me as is.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer


[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux