On Wed, Jul 09, 2014 at 06:32:08PM +0200, Joerg Roedel wrote: > On Tue, Jul 08, 2014 at 06:00:00PM -0400, j.glisse@xxxxxxxxx wrote: > > From: Jérôme Glisse <jglisse@xxxxxxxxxx> > > > > The event information will be usefull for new user of mmu_notifier API. > > The event argument differentiate between a vma disappearing, a page > > being write protected or simply a page being unmaped. This allow new > > user to take different path for different event for instance on unmap > > the resource used to track a vma are still valid and should stay around. > > While if the event is saying that a vma is being destroy it means that any > > resources used to track this vma can be free. > > > > Changed since v1: > > - renamed action into event (updated commit message too). > > - simplified the event names and clarified their intented usage > > also documenting what exceptation the listener can have in > > respect to each event. > > > > Changed since v2: > > - Avoid crazy name. > > - Do not move code that do not need to move. > > Okay, I can actually see use-cases for something like this. Given the > number of invalidate_range_start/end call-sites and the semantics of > these call-backs it would allow certain optimizations to know details of > whats going on between these calls. > > But why do you need this event information for all the other > mmu_notifier call-backs? In change_pte for example you already get the > address and the new pte value, isn't that enough to find out whats going > on? > For hmm no, because hmm do not know the old pte value. Thus have no idea. But right as i am not going to further use change_pte i do not mind much about it so i can drop it for change_pte. But other user might still find that useful as it avoids them to lookup the old pte and do a comparison. Cheers, Jérôme -- 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>