From: Avi Kivity <avi@scylladb.com>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: Mark Wielaard <mjw@redhat.com>, David Smith <dsmith@redhat.com>,
systemtap@sourceware.org
Subject: Re: Some newbie questions
Date: Wed, 17 Aug 2016 15:15:00 -0000 [thread overview]
Message-ID: <e8a55f7f-8ba3-99ba-8ff3-64fabffd6f12@scylladb.com> (raw)
In-Reply-To: <20160811161845.GC12190@redhat.com>
On 08/11/2016 07:18 PM, Frank Ch. Eigler wrote:
> Hi -
>
> avi wrote:
>
>> [...]
>>>> (Have you tried a stap script that merely traps all the same the
>>>> function calls, and has empty probe handlers?)
>>> I can try it.
>> It was actually pretty bad with empty handlers:
>>
>> #
>> 66.25% scylla [kernel.kallsyms] [k] > _raw_spin_lock
>> |
>> ---_raw_spin_lock
>> |
>> |--49.95%-- 0x62ab
>> | syscall_trace_leave
>> [...]
>> |--49.46%-- 0x619b
>> | syscall_trace_enter_phase2
>> [...]
>>
>> I don't have any system call probes. Just two empty static probes, and
>> a timer.profile handler.
> It would sure be nice if perf gave you an explanation of those 0x62ab
> bits. Maybe use dwarf unwind based callgraph collection? The stap
> runtime does sometimes create probes for internal purposes, such as
> trapping exec/mmap operations (so probes on new programs can be
> activated). It is conceivable that this is the source of the spinlock
> activity, but such a high rate doesn't make sense.
I replicated on a more modern machine (also wider: 2s24c48t). I had to
--suppress-time-limits or stap would exit almost immediately.
My load indeed calls epoll_wait() at a high rate, with zero timeout.
But now it's completely dominated by tracing overhead.
#!/usr/bin/stap
# usage: task_latency.stap process_name latency_threshold_ms
global start_time
probe process(@1).mark("reactor_run_tasks_single_start") {
start_time[pid(), tid()] = gettimeofday_us()
}
probe process(@1).mark("reactor_run_tasks_single_end") {
delete start_time[pid(), tid()]
}
probe timer.profile {
if ([pid(), tid()] in start_time) {
now = gettimeofday_us()
start = start_time[pid(), tid()]
if ((now - start) > $2 * 1000) {
printf("detected tasks running for >%sms\n", @2)
print_usyms(ubacktrace())
}
}
}
#
# Total Lost Samples: 357
#
# Samples: 308K of event 'cycles:ppp'
# Event count (approx.): 222398334161
#
# Overhead Command Shared Object Symbol
# ........ ............... ...................
.....................................................................................................................................................................................................................................................
#
50.66% scylla [kernel.kallsyms] [k]
queued_spin_lock_slowpath
|
---queued_spin_lock_slowpath
|
|--49.99%--_raw_spin_lock
| |
| |--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
| | |
reactor_backend_epoll::wait_and_process
| | | |
| | |
|--15.91%--std::_Function_handler<bool (),
reactor::run()::{lambda()#7}>::_M_invoke
| | | | reactor::run
| | | |
smp::configure(boost::program_options::variables_map)::{lambda()#3}::operator()
| | | |
posix_thread::start_routine
| | | | start_thread
| | | | __clone
| | | |
| | |
--7.56%--std::_Function_handler<bool (),
reactor::run()::{lambda()#8}>::_M_invoke
| | | logalloc::tracker::impl::compact_on_idle
| | | reactor::run
| | |
smp::configure(boost::program_options::variables_map)::{lambda()#3}::operator()
| | |
posix_thread::start_routine
| | | start_thread
| | | __clone
| | |
| | --23.27%--utrace_report_syscall_exit
| | syscall_slow_exit_work
| | do_syscall_64
| | return_from_SYSCALL_64
| | |
| | --21.92%--epoll_pwait
| | reactor_backend_epoll::wait_and_process
| | |
| | |--14.83%--std::_Function_handler<bool (),
reactor::run()::{lambda()#7}>::_M_invoke
| | | reactor::run
| | |
smp::configure(boost::program_options::variables_map)::{lambda()#3}::operator()
| | | posix_thread::start_routine
| | | start_thread
| | | __clone
| | |
| | --7.09%--std::_Function_handler<bool (),
reactor::run()::{lambda()#8}>::_M_invoke
| | logalloc::tracker::impl::compact_on_idle
| | reactor::run
| |
smp::configure(boost::program_options::variables_map)::{lambda()#3}::operator()
| | posix_thread::start_routine
| | start_thread
| | __clone
| |
| --1.27%--__lock_task_sighand
| |
| --0.67%--send_sigqueue
| posix_timer_event
| cpu_timer_fire
| run_posix_cpu_timers
| update_process_times
| tick_sched_handle.isra.16
| tick_sched_timer
| __hrtimer_run_queues
| hrtimer_interrupt
:
>
>> Will timer.profile work with dyninst?
> Profile timers, not yet, but normal periodic ones like timer.hz(997) yes.
> Unfortunately backtracing is also not yet implemented there.
>
>
Well, it's not very useful to me then.
next prev parent reply other threads:[~2016-08-17 15:15 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-07 8:08 Avi Kivity
2016-08-07 9:16 ` Avi Kivity
2016-08-08 14:58 ` David Smith
2016-08-09 6:51 ` Avi Kivity
2016-08-09 13:54 ` Mark Wielaard
2016-08-09 14:11 ` Avi Kivity
2016-08-10 15:33 ` Frank Ch. Eigler
2016-08-10 15:39 ` Avi Kivity
2016-08-10 15:40 ` Avi Kivity
2016-08-10 16:47 ` Frank Ch. Eigler
2016-08-11 7:51 ` Avi Kivity
2016-08-11 8:13 ` Avi Kivity
2016-08-11 16:18 ` Frank Ch. Eigler
2016-08-17 15:15 ` Avi Kivity [this message]
2016-08-17 18:06 ` David Smith
2016-08-17 18:22 ` Avi Kivity
2016-08-17 18:10 ` Frank Ch. Eigler
2016-08-17 18:30 ` Avi Kivity
2016-08-17 18:35 ` Frank Ch. Eigler
2016-08-17 18:42 ` Avi Kivity
2016-08-25 16:21 ` Avi Kivity
2016-08-25 17:37 ` David Smith
2016-08-26 18:39 ` Avi Kivity
2016-08-26 20:08 ` David Smith
2016-08-26 21:21 ` Josh Stone
2016-08-28 13:30 ` Avi Kivity
2016-08-28 13:35 ` Avi Kivity
2016-08-28 13:45 ` Avi Kivity
2016-08-29 18:26 ` David Smith
2016-08-31 16:44 ` Avi Kivity
2016-08-09 15:17 ` David Smith
2016-08-09 15:28 ` Avi Kivity
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e8a55f7f-8ba3-99ba-8ff3-64fabffd6f12@scylladb.com \
--to=avi@scylladb.com \
--cc=dsmith@redhat.com \
--cc=fche@redhat.com \
--cc=mjw@redhat.com \
--cc=systemtap@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).