MMU_NOTIFY_PROTECTION_VMA is not specific to NUMA auto-balancing. It can also be the result of an mprotect system call which actually makes the VMA read-only. I don't think it's OK to ignore that notifier in the general case. Regards, Felix Am 2020-08-19 um 2:00 p.m. schrieb Philip Yang: > NUMA auto balancing task_numa_work periodically change memory range > protection proto, in order to trigger CPU page hinting fault when CPU > access the memory later to check if that memory range need to migrate to > different NUMA node. > > GPU can still access the memory after NUMA change the proto because the > memory is not moved yet, so it is safe to ignore the MMU notifier event > MMU_NOTIFY_PROTECTION_VMA to avoid unnecessary queue eviction and > restore. > > Before NUMA auto balancing actually move the memory to different NUMA > node, driver will receive MMU notifier event MMU_NOTIFY_CLEAR to evict > the queues. > > Signed-off-by: Philip Yang <Philip.Yang@xxxxxxx> > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c > index 828b5167ff12..dc4e2317dc31 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c > @@ -106,6 +106,8 @@ static bool amdgpu_mn_invalidate_hsa(struct mmu_interval_notifier *mni, > > if (!mmu_notifier_range_blockable(range)) > return false; > + if (range->event == MMU_NOTIFY_PROTECTION_VMA) > + return true; > > mutex_lock(&adev->notifier_lock); > _______________________________________________ amd-gfx mailing list amd-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/amd-gfx
