This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH v4 2/3] Support for perf to probe into SDT markers:
- From: Pekka Enberg <penberg at iki dot fi>
- To: David Ahern <dsahern at gmail dot com>, Srikar Dronamraju <srikar at linux dot vnet dot ibm dot com>
- Cc: Hemant Kumar <hkshaw at linux dot vnet dot ibm dot com>, LKML <linux-kernel at vger dot kernel dot org>, Peter Zijlstra <peterz at infradead dot org>, Oleg Nesterov <oleg at redhat dot com>, "hegdevasant at linux dot vnet dot ibm dot com" <hegdevasant at linux dot vnet dot ibm dot com>, Ingo Molnar <mingo at redhat dot com>, "anton at redhat dot com" <anton at redhat dot com>, "systemtap at sourceware dot org" <systemtap at sourceware dot org>, Namhyung Kim <namhyung at kernel dot org>, Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>, "aravinda at linux dot vnet dot ibm dot com" <aravinda at linux dot vnet dot ibm dot com>
- Date: Mon, 28 Oct 2013 20:45:23 +0200
- Subject: Re: [PATCH v4 2/3] Support for perf to probe into SDT markers:
- Authentication-results: sourceware.org; auth=none
- References: <20131023044511 dot 1886 dot 82571 dot stgit at hemant-fedora> <20131023050502 dot 1886 dot 15779 dot stgit at hemant-fedora> <CAOJsxLFKm3TxeTmGjbpr1r4sZ8fHcM481-5BM_Cq0J8hhtvBqQ at mail dot gmail dot com> <20131025125921 dot GA29424 at linux dot vnet dot ibm dot com> <F53BA283-A194-4057-8409-27FD3ECFDF2E at iki dot fi> <526A8C2B dot 7000401 at gmail dot com> <526E24EA dot 2040701 at iki dot fi> <526E9808 dot 4030607 at gmail dot com>
On 10/28/13 6:59 PM, David Ahern wrote:
> I often use perf-list to lookup an exact event name, and I do not want
> to see it taking many seconds to minutes to run (not everyone is
> running on an SSD). I also run perf on many different OS versions with
> an NFS home directory, and do not want to see a cache explosion (I
> have buildid disabled for this reason).
I am talking about reasonable defaults - the 'default' part implies that
people can change the behavior. So we absolutely should also have
something like this for power users such as yourself:
perf config sdt.scan false
That said, the 'reasonable' part suggests that 'perf list' must not take
seconds or minutes (!) for every run. I'd start with implementing a
naive scan and seeing where it takes us. It's not like it's rocket
science to ignore network mounts or revert to a whitelist of paths if
necessary.
As for cache explosion, I don't see what the problem is.
If you build a cache of DSOs and executables that have SDT makers (with a
SHA1 hash), the cache size bound by SDT marker annotated files. You
probably can then unconditionally scan the cached filenames for SDT
markers for 'perf list'. And once you see a SHA1 mismatch, you either
rescan automatically or explain to the user that:
SDT marker cache needs to be updated. Please run 'perf list --scan'.
Transparently supporting SDT markers as events for 'perf trace -e' and
others is slightly more tricky because you probably don't want to scan
the files for every 'perf trace' invocation. However, you can probably
get really far with a 1024-entry SDT marker cache that's separate from
the 'executables and DSOs with SDT markers' cache. So whenever the user
does something like
perf trace -e libc:setjmp sleep 1
The 'libc:setjmp' ends up in the 1024-entry cache (or whatever makes
most sense) that points directly to SDT marker so we can hook into it
quickly. Using simple LRU eviction policy, you end up pushing out the
uninteresting SDT markers and keeping the ones that are used all the
time.
Pekka