On 01/25, Ingo Molnar wrote: > > * Oleg Nesterov <o...@redhat.com> wrote: > > > On 01/25, Ingo Molnar wrote: > > > > > > * Srikar Dronamraju <sri...@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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
