Re: [patch 1/2] x86_64 page fault NMI-safe

Ingo Molnar
2010-08-04T07:15:11Z

* Peter Zijlstra <peterz@infradead.org> wrote:

> > What I am proposing does not even involve a copy: when we want to take a
> > snapshot, we just have to force a sub-buffer switch on the ring buffer.
> > The "returns" happening at the beginning of the next (empty) sub-buffer
> > would clearly fail to discard records (expecting non-existing entry
> > records). We would then have to save a small record saying that a function
> > return occurred. The current stack frame at the end of the next sub-buffer
> > could be deduced from the complete collection of stack frame samples.
>
> And suppose the stack-trace was all of 16 entries (not uncommon for a kernel
> stack), then you waste a whole page for 128 bytes (assuming your sub-buffer
> is page sized). I'll take the memcopy, thank you.

To throw some hard numbers into the discussion, i found two random callgraph
perf.data's on my boxes (both created prior the start of this discussion) and
here is the distribution of their call-chain length:

aldebaran:~> perf report -D | grep 'chain: nr:' | cut -d: -f3- | sort -n | uniq -c
2 4
21 6
23 8
13 9
20 10
29 11
21 12
25 13
54 14
112 15
72 16
77 17
35 18
38 19
48 20
29 21
10 22
97 23
3 24
1 25
2 26
2 28
2 29
1 30
2 31

So the peak/average here is around 15 entries.

The other one:

phoenix:~> perf report -D | grep 'chain: nr:' | cut -d: -f3- | sort -n | uniq -c
1 2
70 3
222 4
112 5
116 6
329 7
241 8
163 9
203 10
287 11
159 12
4 13
6 14
22 15
2 16
11 17
5 18

Here the average is even lower - around 8 entries.

Thanks,

Ingo