[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <F53BA283-A194-4057-8409-27FD3ECFDF2E@iki.fi>
Date: Fri, 25 Oct 2013 16:20:54 +0200
From: Pekka Enberg <penberg@....fi>
To: Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
Cc: Pekka Enberg <penberg@...nel.org>,
Hemant Kumar <hkshaw@...ux.vnet.ibm.com>,
LKML <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>,
Oleg Nesterov <oleg@...hat.com>,
"hegdevasant@...ux.vnet.ibm.com" <hegdevasant@...ux.vnet.ibm.com>,
Ingo Molnar <mingo@...hat.com>,
"anton@...hat.com" <anton@...hat.com>,
"systemtap@...rceware.org" <systemtap@...rceware.org>,
Namhyung Kim <namhyung@...nel.org>,
Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
"aravinda@...ux.vnet.ibm.com" <aravinda@...ux.vnet.ibm.com>
Subject: Re: [PATCH v4 2/3] Support for perf to probe into SDT markers:
> Technically feasible. But then we would have to parse each of the
> libraries and executables to list them. Right? I am not sure if such a
> delay is acceptable.
You could do it at 'perf list' time or even build time and cache it. And add lazy discovery to 'perf record' and friends.
> Also if a binary exists in a path thats is not covered in the default
> search, an user might believe that his binary may not have markers.
> I know the above reason is more of a user folly than a tooling issue.
Lazy discovery at 'perf record'-time from executable and DSOs should make that transparent to the user, no? I'm pretty sure it will be fast enough with content-adressed cache.
- Pekka--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists