linux/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c, branch v5.1

mm/mmu_notifier: use structure for invalidate_range_start/end callback

2018-12-28T20:11:50Z

Patch series "mmu notifier contextual informations", v2. This patchset adds contextual information, why an invalidation is happening, to mmu notifier callback. This is necessary for user of mmu notifier that wish to maintains their own data structure without having to add new fields to struct vm_area_struct (vma). For instance device can have they own page table that mirror the process address space. When a vma is unmap (munmap() syscall) the device driver can free the device page table for the range. Today we do not have any information on why a mmu notifier call back is happening and thus device driver have to assume that it is always an munmap(). This is inefficient at it means that it needs to re-allocate device page table on next page fault and rebuild the whole device driver data structure for the range. Other use case beside munmap() also exist, for instance it is pointless for device driver to invalidate the device page table when the invalidation is for the soft dirtyness tracking. Or device driver can optimize away mprotect() that change the page table permission access for the range. This patchset enables all this optimizations for device drivers. I do not include any of those in this series but another patchset I am posting will leverage this. The patchset is pretty simple from a code point of view. The first two patches consolidate all mmu notifier arguments into a struct so that it is easier to add/change arguments. The last patch adds the contextual information (munmap, protection, soft dirty, clear, ...). This patch (of 3): To avoid having to change many callback definition everytime we want to add a parameter use a structure to group all parameters for the mmu_notifier invalidate_range_start/end callback. No functional changes with this patch. [akpm@linux-foundation.org: fix drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c kerneldoc] Link: http://lkml.kernel.org/r/20181205053628.3210-2-jglisse@redhat.com Signed-off-by: Jérôme Glisse Acked-by: Jan Kara Acked-by: Jason Gunthorpe [infiniband] Cc: Matthew Wilcox Cc: Ross Zwisler Cc: Dan Williams Cc: Paolo Bonzini Cc: Radim Krcmar Cc: Michal Hocko Cc: Christian Koenig Cc: Felix Kuehling Cc: Ralph Campbell Cc: John Hubbard Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

mm, oom: distinguish blockable mode for mmu notifiers

2018-08-22T17:52:44Z

There are several blockable mmu notifiers which might sleep in mmu_notifier_invalidate_range_start and that is a problem for the oom_reaper because it needs to guarantee a forward progress so it cannot depend on any sleepable locks. Currently we simply back off and mark an oom victim with blockable mmu notifiers as done after a short sleep. That can result in selecting a new oom victim prematurely because the previous one still hasn't torn its memory down yet. We can do much better though. Even if mmu notifiers use sleepable locks there is no reason to automatically assume those locks are held. Moreover majority of notifiers only care about a portion of the address space and there is absolutely zero reason to fail when we are unmapping an unrelated range. Many notifiers do really block and wait for HW which is harder to handle and we have to bail out though. This patch handles the low hanging fruit. __mmu_notifier_invalidate_range_start gets a blockable flag and callbacks are not allowed to sleep if the flag is set to false. This is achieved by using trylock instead of the sleepable lock for most callbacks and continue as long as we do not block down the call chain. I think we can improve that even further because there is a common pattern to do a range lookup first and then do something about that. The first part can be done without a sleeping lock in most cases AFAICS. The oom_reaper end then simply retries if there is at least one notifier which couldn't make any progress in !blockable mode. A retry loop is already implemented to wait for the mmap_sem and this is basically the same thing. The simplest way for driver developers to test this code path is to wrap userspace code which uses these notifiers into a memcg and set the hard limit to hit the oom. This can be done e.g. after the test faults in all the mmu notifier managed memory and set the hard limit to something really small. Then we are looking for a proper process tear down. [akpm@linux-foundation.org: coding style fixes] [akpm@linux-foundation.org: minor code simplification] Link: http://lkml.kernel.org/r/20180716115058.5559-1-mhocko@kernel.org Signed-off-by: Michal Hocko Acked-by: Christian König # AMD notifiers Acked-by: Leon Romanovsky # mlx and umem_odp Reported-by: David Rientjes Cc: "David (ChunMing) Zhou" Cc: Paolo Bonzini Cc: Alex Deucher Cc: David Airlie Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: Doug Ledford Cc: Jason Gunthorpe Cc: Mike Marciniszyn Cc: Dennis Dalessandro Cc: Sudeep Dutt Cc: Ashutosh Dixit Cc: Dimitri Sivanich Cc: Boris Ostrovsky Cc: Juergen Gross Cc: "Jérôme Glisse" Cc: Andrea Arcangeli Cc: Felix Kuehling Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

drm/amd: Remove errors from sphinx documentation

2018-07-05T21:40:03Z

Eliminating the warnings produced by sphinx when processing the sphinx comments in amdgpu_device.c & amdgpu_mn.c Signed-off-by: Darren Powell Reviewed-by: Michel Dänzer Signed-off-by: Alex Deucher

drm/amdgpu: fix typo in amdgpu_mn.c comments

2018-06-15T17:20:43Z

In doc comments for struct amdgpu_mn: destrution -> destruction Signed-off-by: Slava Abramov Reviewed-by: Christian König Signed-off-by: Alex Deucher

drm/amdgpu: fix documentation of amdgpu_mn.c v2

2018-06-15T17:20:43Z

And wire it up as well. v2: improve the wording, fix label mismatch Signed-off-by: Christian König Reviewed-by: Michel Dänzer Signed-off-by: Alex Deucher

drm/amdgpu: rename rmn to amn in the MMU notifier code (v2)

2018-06-15T17:20:42Z

Just a copy&paste leftover from radeon. v2: rebase (Alex) Signed-off-by: Christian König Reviewed-by: Michel Dänzer Signed-off-by: Alex Deucher

drm/amdgpu: Avoid reclaim while holding locks taken in MMU notifier

2018-03-23T19:32:30Z

When an MMU notifier runs in memory reclaim context, it can deadlock trying to take locks that are already held in the thread causing the memory reclaim. The solution is to avoid memory reclaim while holding locks that are taken in MMU notifiers. This commit fixes kmalloc while holding rmn->lock by moving the call outside the lock. The GFX MMU notifier also locks reservation objects. I have no good solution for avoiding reclaim while holding reservation objects. The HSA MMU notifier will not lock any reservation objects. v2: Moved allocation outside lock instead of using GFP_NOIO Signed-off-by: Felix Kuehling Acked-by: Oded Gabbay Reviewed-by: Christian König Signed-off-by: Oded Gabbay

drm/amdgpu: Add MMU notifier type for KFD userptr

2018-03-23T19:32:28Z

This commit adds the notion of MMU notifier types GFX and HSA. GFX continues to work like MMU notifiers did before. HSA adds support for KFD userptr BOs. The implementation of KFD userptr eviction is a stub for now. Signed-off-by: Felix Kuehling Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay

Merge branch 'drm-next-4.15' of git://people.freedesktop.org/~agd5f/linux into drm-next

2017-09-27T22:37:02Z

First feature pull for 4.15. Highlights: - Per VM BO support - Lots of powerplay cleanups - Powerplay support for CI - pasid mgr for kfd - interrupt infrastructure for recoverable page faults - SR-IOV fixes - initial GPU reset for vega10 - prime mmap support - ttm page table debugging improvements - lots of bug fixes * 'drm-next-4.15' of git://people.freedesktop.org/~agd5f/linux: (232 commits) drm/amdgpu: clarify license in amdgpu_trace_points.c drm/amdgpu: Add gem_prime_mmap support drm/amd/powerplay: delete dead code in smumgr drm/amd/powerplay: delete SMUM_FIELD_MASK drm/amd/powerplay: delete SMUM_WAIT_INDIRECT_FIELD drm/amd/powerplay: delete SMUM_READ_FIELD drm/amd/powerplay: delete SMUM_SET_FIELD drm/amd/powerplay: delete SMUM_READ_VFPF_INDIRECT_FIELD drm/amd/powerplay: delete SMUM_WRITE_VFPF_INDIRECT_FIELD drm/amd/powerplay: delete SMUM_WRITE_FIELD drm/amd/powerplay: delete SMU_WRITE_INDIRECT_FIELD drm/amd/powerplay: move macros to hwmgr.h drm/amd/powerplay: move PHM_WAIT_VFPF_INDIRECT_FIELD to hwmgr.h drm/amd/powerplay: move SMUM_WAIT_VFPF_INDIRECT_FIELD_UNEQUAL to hwmgr.h drm/amd/powerplay: move SMUM_WAIT_INDIRECT_FIELD_UNEQUAL to hwmgr.h drm/amd/powerplay: add new helper functions in hwmgr.h drm/amd/powerplay: use SMU_IND_INDEX/DATA_11 pair drm/amd/powerplay: refine powerplay code. drm/amd/powerplay: delete dead code in hwmgr.h drm/amd/powerplay: refine interface in struct pp_smumgr_func ...

drm/amdgpu: keep the MMU lock until the update ends v4

2017-09-12T18:27:56Z

This is quite controversial because it adds another lock which is held during page table updates, but I don't see much other option. v2: allow multiple updates to be in flight at the same time v3: simplify the patch, take the read side only once v4: correctly fix rebase conflict Signed-off-by: Christian König Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher