Re: [tip:perfcounters/core] perf_counter: x86: Fix call-chain support to use NMI-safe methods

Ingo Molnar
2009-06-15T20:31:02Z

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

>
>
> On Mon, 15 Jun 2009, Ingo Molnar wrote:
> >
> > Well i guess it depends. For server apps it is true - syscalls are a
> > lot more dominant, MMs are long-running so any startup cost gets
> > amortized and pagefaults are avoided.
> >
> > For something like a kernel build we have 7 times as many pagefaults
> > as syscalls:
>
> Ingo - calm down.
>
> This is not about page faults.
>
> This is purely about taps FROM KERNEL SPACE.
>
> Yes, for the kernel build we have 7 times as many page faults as
> system calls, BUT I BET 99.9% of them are from user mode!
>
> The whole "open-code iret" only works for exceptions that happened
> in kernel mode. That's a _vanishingly_ small number (outside of
> device interrupts that happen during idle).

Ah, i misunderstood you, sorry. Yes, you are right.

Btw., we can have a precise number - we can sample all pagefaults
via a soft-counter:

$ perf record -e page-faults -c 1 -f -m 512 -- make -j32

[ perf record: Captured and wrote 783.697 MB perf.data (~34240256 samples) ]

#
# (33858154 samples)
#
# Overhead Symbol
# ........ ......
#
41.62% [.] memset
18.21% 0x007fff07bff634
5.85% [.] __GI_memcpy
5.35% [.] parse_config_file
4.34% [.] _int_malloc
1.24% 0x0000000000dc90
1.14% [k] file_read_actor
1.10% [.] _dl_addr
0.64% [.] __GI_strlen
0.47% [.] _dl_load_cache_lookup
0.43% [.] _dl_cache_libcmp

(i dont have debuginfo installed for that gcc build, hence that raw
entry.)

Kernel triggered pagefaults:

$ perf report -s s | grep '\[k\]'

1.14% [k] file_read_actor
0.15% [k] __clear_user
0.12% [k] strncpy_from_user
0.12% [k] copy_user_generic_string
0.04% [k] __put_user_4
0.04% [k] pipe_read
0.02% [k] load_elf_binary
0.00% [k] do_notify_resume
0.00% [k] iov_iter_fault_in_readable

so 1.7% of the pagefaults are kernel-initiated - 98.3% via
user-space. Your 99.9% figure was within 1.6% of the real number :-)

Ingo