[PATCH 0/2] Optimize mmu_notifier->invalidate_range callback

2017-10-16 Thread jglisse
From: Jérôme Glisse (Andrew you already have v1 in your queue of patch 1, patch 2 is new, i think you can drop it patch 1 v1 for v2, v2 is bit more conservative and i fixed typos) All this only affect user of invalidate_range callback (at this time CAPI arch/powerpc/platforms/powernv/npu-dma.c

[PATCH 1/2] mm/mmu_notifier: avoid double notification when it is useless v2

2017-10-16 Thread jglisse
From: Jérôme Glisse This patch only affects users of mmu_notifier->invalidate_range callback which are device drivers related to ATS/PASID, CAPI, IOMMUv2, SVM ... and it is an optimization for those users. Everyone else is unaffected by it. When clearing a pte/pmd we are given a choice to notify

[PATCH 2/2] mm/mmu_notifier: avoid call to invalidate_range() in range_end()

2017-10-16 Thread jglisse
From: Jérôme Glisse This is an optimization patch that only affect mmu_notifier users which rely on the invalidate_range() callback. This patch avoids calling that callback twice in a row from inside __mmu_notifier_invalidate_range_end Existing pattern (before this patch): mmu_notifier_inval

[PATCH 00/13] mmu_notifier kill invalidate_page callback v2

2017-08-31 Thread jglisse
From: Jérôme Glisse (Sorry for so many list cross-posting and big cc) Changes since v1: - remove more dead code in kvm (no testing impact) - more accurate end address computation (patch 2) in page_mkclean_one and try_to_unmap_one - added tested-by/reviewed-by gotten so far Tested as b

[PATCH 03/13] powerpc/powernv: update to new mmu_notifier semantic

2017-08-31 Thread jglisse
From: Jérôme Glisse Call to mmu_notifier_invalidate_page() are replaced by call to mmu_notifier_invalidate_range() and thus call are bracketed by call to mmu_notifier_invalidate_range_start()/end() Remove now useless invalidate_page callback. Signed-off-by: Jérôme Glisse Cc: linuxppc-dev@lists

[PATCH] mm/mmu_notifier: avoid double notification when it is useless

2017-09-01 Thread jglisse
From: Jérôme Glisse (Note that this is 4.15 material or 4.14 if people are extra confident. I am posting now to get people to test. To that effect maybe it would be a good idea to have that patch sit in linux-next for a while for testing. Other motivation is that the problem is fresh in every