Messages in this thread | | | Date | Fri, 25 Jan 2013 20:34:07 +0100 | From | Oleg Nesterov <> | Subject | Re: [GIT PULL] uprobes: pre-filtering |
| |
On 01/25, Ingo Molnar wrote: > > * Oleg Nesterov <oleg@redhat.com> wrote: > > > On 01/25, Ingo Molnar wrote: > > > > > > * Srikar Dronamraju <srikar@linux.vnet.ibm.com> wrote: > > > > > > > The other alternative is to extend the current abi and pass > > > > the prefilter option. Should we extend the abi for userspace > > > > tracing is obviously debatable. > > > > > > That's the obvious path to go - why add something to the kernel > > > if user-space cannot make use of it? > > > > This is what I am going to (try to) do, but I am not sure if this makes > > sense... > > > > For the start, can't we teach 'uprobe_events' file to accept, say, > > > > 'p file:0x1234 pid=1 other-opts' > > > > for the start? This looks simple enough, and I after looked > > into tools/perf it seems that perf can be changed too. > > > > What do you think? > > Sounds sensible and functional to me.
Great, thanks.
> > Then we can extend 'pid=' option to accept the list of pids, > > perhaps. > > > > In the long term we probably need uprobes/pid_filter or > > something like this, it should allow to add/del pid > > dynamically. I really do not know. > > For now removing+adding a new one should be enough to 'change' a > uprobe, right?
Yes, yes. I meant that obviously we can do more/better to filter-out the tasks we do not want to probe. But this need more changes, and more importantly this needs more discussion about API/ABI/etc.
Thanks.
Oleg.
| |