Re: [announce] Performance Counters for Linux, v6

[Corey Ashford]

Peter Zijlstra wrote:
> On Fri, 2009-02-20 at 14:38 -0800, Corey Ashford wrote:
> > There may be other non-event-related changes that will not be handled 
> > quite as well in this way.  In the original email I hinted at that we 
> > may want an option for mmap'd sample buffers at some point, and so I'm 
> > not clear how you'd provide an ABI to request mmap'd buffers (you would 
> > probably need to be able to request the size and get back a pointer to 
> > the mmap'd buffer).  Would this be done through a special 
> > sys_perf_counter_open call?  Or through a subsequent ioctl call on the 
> > group leader after an open (which requires the counters to be initially 
> > disabled), etc.
>
> What's stopping a regular mmap() call using the fd obtained from
> sys_perf_counter_open() ?

Thinking about this some more, I'm not sure it is the right model to be 
able to read a stream of records up from kernel space.

Let's say I want to read 1MB of records up at once, and then a bit later 
read another 1MB, and so on, all while the program is still running and 
counters are counting.  Is there a way to use mmap this way?  I think I 
would have to call mmap for each 1MB segment (if my buffer is 1MB). 
Also how do I indicate to the kernel that I've "consumed" each 1MB chunk 
and that the kernel buffers for it can be reused?  It's easy to 
understand how to do that with just a read() call, but with mmap'd 
memory, I don't know.

Another thing that concerns me is this statement in the mmap() man page: 
"If the size of the mapped file changes after the call to mmap() as a 
result of some other operation on the mapped file, the effect of 
references to portions of the mapped region that correspond to added or 
removed portions of the file is unspecified."  Would PCL guarantee the 
correct contents of memory, despite this caveat?

If you wait till after you've stopped the counters to read up the 
records, I can see where mmap would work fine.  But if you are trying to 
unload the data from the kernel's space efficiently, over the long 
execution time of the thread or process being analyzed, I don't see how 
mmap can be used in this way on PCL's file descriptors.

In perfmon, the model is different, because the mmap'd memory for the 
buffer is not streamed; it's just a block of memory full of records. 
Once one buffer fills up, user space is alerted and the kernel
inhibits adding new entries (in single-buffering mode), while user space 
accesses the filled buffer.  So the mmap call has to be done only once. 
 Double-buffering (or more) can be achieved by splitting the buffer 
into multiple pieces and filling them up separately and alerting user 
space when each are full.

Quite possibly I'm missing something obvious, but PCL may need an mmap 
behavior better suited for efficiently reading data up dynamically over 
the long run of the program being analyzed.

Regards,

- Corey

Corey Ashford
Software Engineer
IBM Linux Technology Center, Linux Toolchain
Beaverton, OR
503-578-3507
cjashfor@xxxxxxxxxx

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/