On Mon, 2012-04-16 at 23:47 +0200, Oleg Nesterov wrote: > On 04/16, Peter Zijlstra wrote: > > > > On Mon, 2012-04-16 at 01:44 +0200, Oleg Nesterov wrote: > > > > > And. I have another reason for down_write() in register/unregister. > > > I am still not sure this is possible (I had no time to try to > > > implement), but it seems to me we can kill the uprobe counter in > > > mm_struct. > > > > You mean by making register/unregister down_write, you're exclusive with > > munmap() > > .. and with register/unregister. > > Why do we need mm->uprobes_state.count? It is writeonly, except we > check it in the DIE_INT3 notifier before anything else to avoid the > unnecessary uprobes overhead. and uprobe_munmap(). > Suppose we kill it, and add the new MMF_HAS_UPROBE flag instead. > install_breakpoint() sets it unconditionally, > uprobe_pre_sstep_notifier() checks it. Argh, why are MMF_flags part of sched.h.. one would expect those to be in mm.h or mm_types.h.. somewhere near struct mm. > (And perhaps we can stop right here? I mean how often this can > slow down the debugger which installs int3 in the same mm?) > > Now we need to clear MMF_HAS_UPROBE somehowe, when the last > uprobe goes away. Lets ignore uprobe_map/unmap for simplicity. > > - We add another flag, MMF_UPROBE_RECALC, it is set by > remove_breakpoint(). > > - We change handle_swbp(). Ignoring all details it does: > > if (find_uprobe(vaddr)) > process_uprobe(); > else if (test_bit(MMF_HAS_UPROBE) && test_bit(MMF_UPROBE_RECALC)) > recalc_mmf_uprobe_flag(); > > where recalc_mmf_uprobe_flag() checks all vmas and either > clears both flags or MMF_UPROBE_RECALC only. > > This is the really slow O(n) path, but it can only happen after > unregister, and only if we hit another non-uprobe breakpoint > in the same mm. > > Something like this. What do you think? I think I can live with the simple set MMF_HAS_UPROBE and leave it at that. The better optimization seems to be to not install breakpoints when ->filter() excludes the task.. It looks like we currently install the breakpoint unconditionally and only ->filter() once we hit the breakpoint, which is somewhat sub-optimal. -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>