Messages in this thread | | | Date | Sun, 2 Aug 2009 21:46:37 +0200 | From | Ingo Molnar <> | Subject | Re: perf_counter: Track all mmaps, heap and stack extensions |
| |
* Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> On Tue, 2009-07-28 at 18:46 +1000, Anton Blanchard wrote: > > Hi, > > > > Right now perf_counter only logs executable mmaps. While this is enough > > for instruction profiling, at some stage we are also going to want > > to do data profiling. This will require us to log non-executable mmaps as > > well as stack and heap extensions. > > > > Why would we care about heap and stack? A few examples: > > > > 1. We can monitor TLB miss rates to suggest what regions of memory should be > > put into hugepages. > > > > 2. We can look into various TLB miss issues. On PowerPC a data prefetch > > that goes to an unmapped area takes a significant amount of time (it > > initiates a tablewalk that may take 40+ cycles). With accurate mapping > > data we can catch areas of code with bad prefetch instructions. > > Agreed. > > > Taking it a bit further, since in some sense perf_counter is a channel for > > getting events out to userspace, I wonder if we could solve Roland's RDMA > > address space unmap issue with perf_counter: > > > > http://patchwork.kernel.org/patch/37267/ > > Yeah, saw some of that, Andrew has some good points there. Haven't had > time to see the reply yet. > > Not sure its a good match, but if so, very nice. > > > Below is a dodgy hack I've been using to prototype tracking of > > all mmaps and heap/stack extensions. Naturally we'd want a > > perf_counter feature to turn this on and keep instruction > > profiles more compact. We'd also want munmap events. > > I used to have an munmap hook in there at some point. We could > restore that. > > > Thoughts? > > Seems like a good direction, go for it ;-)
Seconded! Please submit the full patch once you are happy with it, with some tools/perf/ variant/feature that makes use of it and we are golden.
Ingo
| |