* Srikar Dronamraju [off-list ref] wrote:

quoted

We already have some other vma tracking goodies in perf 
itself (see perf_event_mmap() et al) - would it make sense 
to merge the two vma instrumentation facilities and not 
burden mm/ with two separate sets of callbacks?

Atleast for file backed vmas, perf_event_mmap seems to be 
interested in just the new vma creations. Uprobes would also 
be interested in the size changes like the vma 
growing/shrinking/remap. Is perf_event_mmap interested in such 
changes? From what i could see, perf_event_mmap seems to be 
interested in stack vma size changes but not file vma size 
changes.

I don't think perf_event_mmap() would be hurt from getting more 
callbacks, as long as there's enough metadata to differentiate 
the various events from each other.

( In the long run we really want all such callbacks to be
  tracepoints so that we can make them even less intrusive via
  jump label patching optimizations, etc. - but we are not there
  yet. )

Also mmap_uprobe gets called in fork path. Currently we have a 
hook in copy_mm/dup_mm so that we get to know the context of 
each vma that gets added to the child and add its breakpoints. 
At dup_mm/dup_mmap we would have taken mmap_sem for both 
parent and child so there is no way we could have missed a 
register/unregister in the parent not reflected in the child.

I see the perf_event_fork but that would have to enhanced to 
do a lot more to help us do a mmap_uprobe.

Andrew's call i guess.

I did not suggest anything complex or intrusive: just basically 
unify the namespace, have a single set of callbacks, and call 
into the uprobes and perf code from those callbacks - out of the 
sight of MM code.

That unified namespace could be called:

    event_mmap(...);
    event_fork(...);

etc. - and from event_mmap() you could do a simple:

	perf_event_mmap(...)
	uprobes_event_mmap(...)

[ Once all this is updated to use tracepoints it would turn into 
  a notification callback chain kind of thing. ]

quoted

If all such issues are resolved then i guess we could queue 
up uprobes in -tip, conditional on it remaining sufficiently 
regression-, problem- and NAK-free.

Okay. Accepting uprobes into tip, would provide more 
testing/feedback.

quoted

Also, it would be nice to hear Arnaldo's opinion about the 
tools/perf/ bits.

Whatever comments Arnaldo/Masami have given till now have been 
resolved.

Please see the probe installation syntax feedback i've sent in 
the previous mail - that needs to be addressed too.

You should think with the head of an ordinary user-space 
developer who wants to say debug a library and wants to use 
uprobes for that. What would he have to type to achieve that and 
is what he types the minimum number of characters to reasonably 
achieve that goal?

Thanks,

	Ingo

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  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@kvack.org"> email@kvack.org </a>