Messages in this thread | | | Date | Tue, 19 Nov 2013 09:09:40 -0700 | From | David Ahern <> | Subject | Re: [PATCH 4/5] perf record: mmap output file - v5 |
| |
On 11/19/13, 8:31 AM, Ingo Molnar wrote: >> The only reason I reacted was because the changelog mentioned >> avoiding a feedback loop -- so I obviously had to point out that it >> didn't do such a thing, it only changed the details of the loop. > > So with MAP_POPULATE the 'feedback window' is moved entirely into the > kernel (to within a single syscall) and is also reduced significantly, > compared to a write() loop.
As I understand it we have to use MAP_SHARED, not MAP_PRIVATE for files. So MAP_POPULATE does not work here. (And I tried to verify -- MAP_PRIVATE | MAP_POPULATE drops the feedback loop, but the file is 0's after the header).
>> I'm fairly certain this particular problem is unavoidable, no matter >> what the mechanism used, you can always create feedback. > > Well, we could exclude the profiling task itself from profiling events > (just like ftrace and core bits of perf does it out of necessity), but > I intentionally wanted to avoid that, to make sure we are honest and > to make sure people don't tolerate profiling overhead that disturbs > other workloads.
Samples generated by perf itself need to be observable -- e.g. process scheduling I want to see the time consumed by the data collector itself and there are times when 'perf trace -- perf ...' is useful.
perf just needs options to do the right thing and stay out of its own way. Having a restriction that you can't do system wide collection of systems calls AND faults does not seem all that limiting.
David
| |