search for: mmu_notifier_invalidate_range_start

...a ("Merge remote-tracking branch 'hmm/hmm'") ============================================ WARNING: possible recursive locking detected 5.3.0-rc6-next-20190830 #75 Not tainted -------------------------------------------- oom_reaper/1065 is trying to acquire lock: ffffffff8904ff60 (mmu_notifier_invalidate_range_start){+.+.}, at: __mmu_notifier_invalidate_range_end+0x0/0x360 mm/mmu_notifier.c:169 but task is already holding lock: ffffffff8904ff60 (mmu_notifier_invalidate_range_start){+.+.}, at: __oom_reap_task_mm+0x196/0x490 mm/oom_kill.c:542 other info that might help us debug this: Possible unsafe lock...

On Thu, Jul 23, 2020 at 03:30:04PM -0700, Ralph Campbell wrote: > When migrating the special zero page, migrate_vma_pages() calls > mmu_notifier_invalidate_range_start() before replacing the zero page > PFN in the CPU page tables. This is unnecessary since the range was > invalidated in migrate_vma_setup() and the page table entry is checked > to be sure it hasn't changed between migrate_vma_setup() and > migrate_vma_pages(). Therefore, remove the...

...98.442408] [ 98.442408] the existing dependency chain (in reverse order) is: [ 98.449899] [ 98.449899] -> #3 (&svmm->mutex){+.+.}: [ 98.455249] __mutex_lock+0x134/0xc70 [ 98.459526] nouveau_svmm_invalidate_range_start+0x71/0x110 [nouveau] [ 98.466593] __mmu_notifier_invalidate_range_start+0x25c/0x320 [ 98.473031] unmap_vmas+0x10c/0x200 [ 98.477130] unmap_region+0x1a4/0x240 [ 98.481410] __do_munmap+0x3e0/0x750 [ 98.485535] __vm_munmap+0xbc/0x130 [ 98.489599] __x64_sys_munmap+0x3c/0x50 [ 98.493951] do_syscall_64+0x68/0x280 [ 98.4...

On Tue, Jul 28, 2020 at 03:04:07PM -0700, Ralph Campbell wrote: > > On 7/28/20 12:19 PM, Jason Gunthorpe wrote: > > On Thu, Jul 23, 2020 at 03:30:04PM -0700, Ralph Campbell wrote: > > > When migrating the special zero page, migrate_vma_pages() calls > > > mmu_notifier_invalidate_range_start() before replacing the zero page > > > PFN in the CPU page tables. This is unnecessary since the range was > > > invalidated in migrate_vma_setup() and the page table entry is checked > > > to be sure it hasn't changed between migrate_vma_setup() and > > > mi...

Currently migrate_vma_setup() calls mmu_notifier_invalidate_range_start() which flushes all device private page mappings whether or not a page is being migrated to/from device private memory. In order to not disrupt device mappings that are not being migrated, shift the responsibility for clearing device private mappings to the device driver and leave CPU page table un...

Currently migrate_vma_setup() calls mmu_notifier_invalidate_range_start() which flushes all device private page mappings whether or not a page is being migrated to/from device private memory. In order to not disrupt device mappings that are not being migrated, shift the responsibility for clearing device private mappings to the device driver and leave CPU page table un...

When migrating the special zero page, migrate_vma_pages() calls mmu_notifier_invalidate_range_start() before replacing the zero page PFN in the CPU page tables. This is unnecessary since the range was invalidated in migrate_vma_setup() and the page table entry is checked to be sure it hasn't changed between migrate_vma_setup() and migrate_vma_pages(). Therefore, remove the redundant invalidat...

On 7/28/20 12:19 PM, Jason Gunthorpe wrote: > On Thu, Jul 23, 2020 at 03:30:04PM -0700, Ralph Campbell wrote: >> When migrating the special zero page, migrate_vma_pages() calls >> mmu_notifier_invalidate_range_start() before replacing the zero page >> PFN in the CPU page tables. This is unnecessary since the range was >> invalidated in migrate_vma_setup() and the page table entry is checked >> to be sure it hasn't changed between migrate_vma_setup() and >> migrate_vma_pages(). There...

Currently migrate_vma_setup() calls mmu_notifier_invalidate_range_start() which flushes all device private page mappings whether or not a page is being migrated to/from device private memory. In order to not disrupt device mappings that are not being migrated, shift the responsibility for clearing device private mappings to the device driver and leave CPU page table un...

Currently migrate_vma_setup() calls mmu_notifier_invalidate_range_start() which flushes all device private page mappings whether or not a page is being migrated to/from device private memory. In order to not disrupt device mappings that are not being migrated, shift the responsibility for clearing device private mappings to the device driver and leave CPU page table un...

...ange = vhost_invalidate_range, > +}; > + > void vhost_dev_init(struct vhost_dev *dev, > struct vhost_virtqueue **vqs, int nvqs, int iov_limit) > { I also wonder here: when page is write protected then it does not look like .invalidate_range is invoked. E.g. mm/ksm.c calls mmu_notifier_invalidate_range_start and mmu_notifier_invalidate_range_end but not mmu_notifier_invalidate_range. Similarly, rmap in page_mkclean_one will not call mmu_notifier_invalidate_range. If I'm right vhost won't get notified when page is write-protected since you didn't install start/end notifiers. Note that end...

...ange = vhost_invalidate_range, > +}; > + > void vhost_dev_init(struct vhost_dev *dev, > struct vhost_virtqueue **vqs, int nvqs, int iov_limit) > { I also wonder here: when page is write protected then it does not look like .invalidate_range is invoked. E.g. mm/ksm.c calls mmu_notifier_invalidate_range_start and mmu_notifier_invalidate_range_end but not mmu_notifier_invalidate_range. Similarly, rmap in page_mkclean_one will not call mmu_notifier_invalidate_range. If I'm right vhost won't get notified when page is write-protected since you didn't install start/end notifiers. Note that end...

On Mon, Jul 06, 2020 at 03:23:45PM -0700, Ralph Campbell wrote: > Currently migrate_vma_setup() calls mmu_notifier_invalidate_range_start() > which flushes all device private page mappings whether or not a page > is being migrated to/from device private memory. In order to not disrupt > device mappings that are not being migrated, shift the responsibility > for clearing device private mappings to the device driver and lea...

On Mon, Jul 13, 2020 at 10:21:47AM -0700, Ralph Campbell wrote: > Currently migrate_vma_setup() calls mmu_notifier_invalidate_range_start() > which flushes all device private page mappings whether or not a page > is being migrated to/from device private memory. In order to not disrupt > device mappings that are not being migrated, shift the responsibility > for clearing device private mappings to the device driver and lea...

The goal for this series is to avoid device private memory TLB invalidations when migrating a range of addresses from system memory to device private memory and some of those pages have already been migrated. The approach taken is to introduce a new mmu notifier invalidation event type and use that in the device driver to skip invalidation callbacks from migrate_vma_setup(). The device driver is

...*dev, > > > struct vhost_virtqueue **vqs, int nvqs, int iov_limit) > > > { > > > > I also wonder here: when page is write protected then > > it does not look like .invalidate_range is invoked. > > > > E.g. mm/ksm.c calls > > > > mmu_notifier_invalidate_range_start and > > mmu_notifier_invalidate_range_end but not mmu_notifier_invalidate_range. > > > > Similarly, rmap in page_mkclean_one will not call > > mmu_notifier_invalidate_range. > > > > If I'm right vhost won't get notified when page is write-protected sinc...

...*dev, > > > struct vhost_virtqueue **vqs, int nvqs, int iov_limit) > > > { > > > > I also wonder here: when page is write protected then > > it does not look like .invalidate_range is invoked. > > > > E.g. mm/ksm.c calls > > > > mmu_notifier_invalidate_range_start and > > mmu_notifier_invalidate_range_end but not mmu_notifier_invalidate_range. > > > > Similarly, rmap in page_mkclean_one will not call > > mmu_notifier_invalidate_range. > > > > If I'm right vhost won't get notified when page is write-protected sinc...

...t nvqs, int iov_limit) > > > > > { > > > > I also wonder here: when page is write protected then > > > > it does not look like .invalidate_range is invoked. > > > > > > > > E.g. mm/ksm.c calls > > > > > > > > mmu_notifier_invalidate_range_start and > > > > mmu_notifier_invalidate_range_end but not mmu_notifier_invalidate_range. > > > > > > > > Similarly, rmap in page_mkclean_one will not call > > > > mmu_notifier_invalidate_range. > > > > > > > > If I'm right vh...

...t nvqs, int iov_limit) > > > > > { > > > > I also wonder here: when page is write protected then > > > > it does not look like .invalidate_range is invoked. > > > > > > > > E.g. mm/ksm.c calls > > > > > > > > mmu_notifier_invalidate_range_start and > > > > mmu_notifier_invalidate_range_end but not mmu_notifier_invalidate_range. > > > > > > > > Similarly, rmap in page_mkclean_one will not call > > > > mmu_notifier_invalidate_range. > > > > > > > > If I'm right vh...

...t nvqs, int iov_limit) > > > > > { > > > > I also wonder here: when page is write protected then > > > > it does not look like .invalidate_range is invoked. > > > > > > > > E.g. mm/ksm.c calls > > > > > > > > mmu_notifier_invalidate_range_start and > > > > mmu_notifier_invalidate_range_end but not mmu_notifier_invalidate_range. > > > > > > > > Similarly, rmap in page_mkclean_one will not call > > > > mmu_notifier_invalidate_range. > > > > > > > > If I'm right vh...