On Wed, May 07, 2014 at 05:14:52PM +1000, Benjamin Herrenschmidt wrote: > On Tue, 2014-05-06 at 12:18 -0400, Jerome Glisse wrote: > > > > I do understand that i was pointing out that if i move to, tlb which i > > am fine with, i will still need to sleep there. That's all i wanted to > > stress, i did not wanted force using mmu_notifier, i am fine with them > > becoming atomic as long as i have a place where i can intercept cpu > > page table update and propagate them to device mmu. > > Your MMU notifier can maintain a map of "dirty" PTEs and you do the > actual synchronization in the subsequent flush_tlb_* , you need to add > hooks there but it's much less painful than in the notifiers. > > *However* Linus, even then we can't sleep. We do things like > ptep_clear_flush() that need the PTL and have the synchronous flush > semantics. > > Sure, today we wait, possibly for a long time, with IPIs, but we do not > sleep. Jerome would have to operate within a similar context. No sleep > for you :) > > Cheers, > Ben. > > So Linus, Benjamin is right there was couple case i did not think about. For instance with cow page, one thread might trigger copy on write allocate new page and update page table and another cpu thread might start using the new page before we even get a chance to update the GPU page table thus GPU could be working on outdated data. Same kind of race exist on fork when we write protect a page or on when we split a huge page. I thought that i only needed to special case page reclaimation, migration and forbid things like ksm but i am wrong. So with that in mind are you ok if i pursue the mmu_notifier case taking into account the result about rwsem+optspin that would allow to make the many fork workload fast while still allowing mmu_notifier callback to sleep ? Otherwise i have no other choice than to add something like mmu_notifier in the place where there can a be race (huge page split, cow, ...). Which sounds like a bad idea to me when mmu_notifier is perfect for the job. Cheers, Jérôme Glisse -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>