Messages in this thread | | | Date | Wed, 13 Nov 2013 12:50:21 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH 4/5] perf record: mmap output file - v5 |
| |
* Peter Zijlstra <peterz@infradead.org> wrote:
> On Tue, Nov 12, 2013 at 10:11:21PM +0100, Ingo Molnar wrote: > > > > * David Ahern <dsahern@gmail.com> wrote: > > > > > > Dunno.. it _should_ all work. Try it and see what it does.. Once the > > > > events are bigger than a page things might get 'interesting' though. > > > > Which could be the case with call-graph recording, right? > > Not typically, I think we're limiting call graphs to 127 u64, which is > ~1k. Maybe you can blow the single page if you also do a large > top-of-stack copy for dwarf/unwind nonsense.
What I meant was dwarf style call graph recording:
tools/perf/builtin-record.c: const unsigned long default_stack_dump_size = 8192;
Doesn't that mean 8K+ events?
> > > one option here is not allow page faults and system wide system > > > calls. system wide tracing needs mmap; page faults for a task can > > > use write(). I left that option in case something like this came up. > > > > So maybe splice() sounds like the right long term solution after all? > > :-/ > > Right until you put a tracepoint (kprobe) somewhere in whatever function > is used to transfer a single page into/from a splice pipe.
That ought to be a far less common occurance than tracing page faults though.
> You can always screw yourself over using this stuff, no exceptions.
Granted, as the many notrace markings demonstrate this stuff really wants to observe itself observing itself all the time! :)
Thanks,
Ingo
| |