Re: [PATCHv11 2.6.36-rc2-tip 0/15] 0: Uprobes Patches

[Christoph Hellwig <hch@infradead.org>]

On Fri, Oct 29, 2010 at 04:18:58PM +0530, Srikar Dronamraju wrote:
> Current issues: Given a vma; finding all tasks that have this vma
> mapped. The current solution seems to walk thro all tasks in the system
> and check if each task's mm field. But this could be inefficient
> especially if the vma is part of all processes like libc etc.

It's pretty much guaranteed to be inefficient, yes.

> I dont think we can use mm->owner to walk thro all the tasks that map to
> this mm_struct.

I don't see a way around that if we have to find the task by the vma.

You'll have to start with vma->vm_mm->owner and then walk the list
of thread siblings inside the heavy weight process.

> Slot allocation delays: Using a per-thread slot instead of a per-probe
> slot leads to a 3.5X degradation in performance. If we need to use
> per-probe slots, we would have to have maintain metadata, i.e the slot
> to virtual address mapping per process. However Peter prefers that we
> reduce such metadata.

The performance numbers are pretty drastic.  But I'll let Peter comment
on the desire in more detail.  I'm really not in enough touch with this
code anymore to give too useful comments.

> >From a perf/ftrace perspective:

I really prefer the new interface.  But as said before I'm just a user
here and I don't care how it's implemented underneath.  I'll defer to
Peter and others knowing the code in more detail to make the trade offs
between the different low level implementations.