Some newbie questions
Avi Kivity
avi@scylladb.com
Wed Aug 17 18:30:00 GMT 2016
On 08/17/2016 09:10 PM, Frank Ch. Eigler wrote:
> avi wrote:
>
>> [...]
>> My load indeed calls epoll_wait() at a high rate, with zero timeout.
> OK. That's an unusual and cpu-saturating method. Without systemtap
> active, the code must be doing millions of syscalls per second. Are
> you sure there's no better way?
Yes. It's not very common, but some high throughput or latency
sensitive applications will poll. In my case it's both high throughput
and latency sensitive.
In any case, asking users to do fewer syscalls because it hurts
systemtap will not work.
>
>> But now it's completely dominated by tracing overhead.
>> [...]
>> | |--48.48%--task_utrace_struct
>> | | |--25.21%--utrace_report_syscall_entry
>> | | | syscall_trace_enter_phase2
>> | | | syscall_trace_enter
>> | | | do_syscall_64
>> | | | return_from_SYSCALL_64
>> | | | |
>> | | | --23.47%--epoll_pwait
>> [...]
> OK, this implicates the systemtap runtime utrace-emulation code that
Why is it emulating? Is there something missing in Kconfig? This is a
4.6 Fedora kernel, so I expect the kitchen sink has been compiled in.
> looks for mmap/exec syscalls. Perhaps there could be a mode (a -D
> setting?) for selecting kprobes rather than syscall-tracepoints to
> catch those events.
>
Why not trace just mmap and exec syscalls, rather than everything?
Surely there's a static tracepoint for those.
I'd say defaulting to taking a spinlock on every syscall is going to
cause anyone who's using more than a laptop a lot of pain.
More information about the Systemtap
mailing list