On Mon, 2009-04-06 at 14:33 -0700, Corey Ashford wrote:Peter Zijlstra wrote:On Mon, 2009-04-06 at 14:15 -0700, Corey Ashford wrote:Oh I see. In PAPI, the user specifies the range(s) of addresses he's interested in profiling (any sampled IP's outside the requested ranges are discarded), and so as long as the kernel space IP's don't overlap with user space IP's, we should be fine.Peter Zijlstra wrote:Ah, we called it level before, the hv/kernel/user thing. For remoteOn Mon, 2009-04-06 at 13:16 -0700, Corey Ashford wrote:Self-profiling mainly, yes. PAPI specs an ability for remote monitoring of processes and threads, but I think it's only partially implemented.
Self-profiling?I think it would. For one use case I'm working on right now, simple profiling, all I need are ip's. If I could omit the header, that would reduce the frequency of sigio's by a factor of three, and make it faster to read up the ip's when the SIGIO's occur.One downside of this approach is that you if you specify "no header" (currently not possible, but maybe later?), you will not be able to get the level bits.Would this be desirable?
So you're interested in getting the smallest possible record size, that
would still be 2 u64, right? Otherwise you don't get the IP context that
started this.
So when you are talking about IP context, you mean pid/tid?
profiling you'd want to have the mmap thing too.
Ah, while this would be true for most 'sane' architectures, Paul was
right in pointing out that this is not true for all architectures -- and
we should therefore not rely on address range alone.
You could of course use: hw_event.exclude_{hv,kernel} = 1 to ensure you
only get userspace thingies I suppose (but then you have no way of
telling how many you missed I guess).