SlideShare a Scribd company logo
Brought to you by
New ways to find
latency in Linux using
tracing
Steven Rostedt
Open Source Engineer at VMware
©2021 VMware, Inc.
New ways to find
latency in Linux
using tracing
Steven Rostedt
Open Source Engineer
srostedt@vmware.com
twitter: @srostedt
What is ftrace?
●
Official tracer of the Linux Kernel
– Introduced in 2008
●
Came from the PREEMPT_RT patch set
– Initially focused on finding causes of latency
●
Has grows significantly since 2008
– Added new ways to find latency
– Does much more than find latency
The ftrace interface (the tracefs file system)
# mount -t tracefs nodev /sys/kernel/tracing
# ls /sys/kernel/tracing
available_events max_graph_depth snapshot
available_filter_functions options stack_max_size
available_tracers osnoise stack_trace
buffer_percent per_cpu stack_trace_filter
buffer_size_kb printk_formats synthetic_events
buffer_total_size_kb README timestamp_mode
current_tracer recursed_functions trace
dynamic_events saved_cmdlines trace_clock
dyn_ftrace_total_info saved_cmdlines_size trace_marker
enabled_functions saved_tgids trace_marker_raw
error_log set_event trace_options
eval_map set_event_notrace_pid trace_pipe
events set_event_pid trace_stat
free_buffer set_ftrace_filter tracing_cpumask
function_profile_enabled set_ftrace_notrace tracing_max_latency
hwlat_detector set_ftrace_notrace_pid tracing_on
instances set_ftrace_pid tracing_thresh
kprobe_events set_graph_function uprobe_events
kprobe_profile set_graph_notrace uprobe_profile

Recommended for you

Deep dive into PostgreSQL statistics.
Deep dive into PostgreSQL statistics.Deep dive into PostgreSQL statistics.
Deep dive into PostgreSQL statistics.

Pgconf US 2016 slides

Linuxのプロセススケジューラ(Reading the Linux process scheduler)
Linuxのプロセススケジューラ(Reading the Linux process scheduler)Linuxのプロセススケジューラ(Reading the Linux process scheduler)
Linuxのプロセススケジューラ(Reading the Linux process scheduler)

NLKB-005

schedulerlinuxkernel
Evolution of MongoDB Replicaset and Its Best Practices
Evolution of MongoDB Replicaset and Its Best PracticesEvolution of MongoDB Replicaset and Its Best Practices
Evolution of MongoDB Replicaset and Its Best Practices

There are several exciting and long-awaited features released from MongoDB 4.0. He will focus on the prime features, the kind of problem it solves, and the best practices for deploying replica sets.

mongodb 4.0mongodbmydbops
Introducing trace-cmd
Luckily today, we do not need to know all those files
●
trace-cmd is a front end interface to ftrace
●
It interfaces with the tracefs directory for you
https://www.trace-cmd.org
git clone git://git.kernel.org/pub/scm/utils/trace-cmd/trace-cmd.git
The Old Tracers
●
Wake up trace
– All tasks
– RT tasks
– Deadline Tasks
●
Preemption off tracers
– irqsoff tracer
– preemptoff tracer
– preemptirqsoff tracer
Wake up tracer
Task 1
Interrupt
Wake up Task 2 event
Task 2
Sched switch event
latency
Running wakeup_rt tracer
# trace-cmd start -p wakeup_rt
# trace-cmd show
# tracer: wakeup_rt
#
# wakeup_rt latency trace v1.1.5 on 5.10.52-test-rt47
# latency: 94 us, #211/211, CPU#4 | (M:preempt_rt VP:0, KP:0, SP:0 HP:0 #P:8)
# -----------------
# | task: rcuc/4-42 (uid:0 nice:0 policy:1 rt_prio:1)
# -----------------
#
# _--------=> CPU#
# / _-------=> irqs-off
# | / _------=> need-resched
# || / _-----=> need-resched-lazy
# ||| / _----=> hardirq/softirq
# |||| / _---=> preempt-depth
# ||||| / _--=> preempt-lazy-depth
# |||||| / _-=> migrate-disable
# ||||||| / delay
# cmd pid |||||||| time | caller
#  / ||||||||  | /
bash-1872 4dN.h5.. 1us+: 1872:120:R + [004] 42: 98:R rcuc/4
bash-1872 4dN.h5.. 30us : <stack trace>
=> __ftrace_trace_stack
=> probe_wakeup
=> ttwu_do_wakeup
=> try_to_wake_up

Recommended for you

MaxScale이해와활용-2023.11
MaxScale이해와활용-2023.11MaxScale이해와활용-2023.11
MaxScale이해와활용-2023.11

Maxscale 이해와 활용. 202311

#maxscale#mariadb #dbproxy#opensource
MySQL Parallel Replication by Booking.com
MySQL Parallel Replication by Booking.comMySQL Parallel Replication by Booking.com
MySQL Parallel Replication by Booking.com

Since 5.7.2, MySQL implements parallel replication in the same schema, also known as LOGICAL_CLOCK (DATABASE based parallel replication is also implemented in 5.6 but this is not covered in this talk). In early 5.7 versions, parallel replication was based on group commit (like MariaDB) and 5.7.6 changed that to intervals. Intervals are more complicated but they are also more powerful. In this talk, I will explain in detail how they work and why intervals are better than group commit. I will also cover how to optimize parallel replication in MySQL 5.7 and what improvements are coming in MySQL 8.0.

binlog serversbooking.commysql
Galera cluster for high availability
Galera cluster for high availability Galera cluster for high availability
Galera cluster for high availability

Galera Cluster is high availabiity solution in MySQL. It benefits organizations that need synchronous and high availability solution.

databasegaleracluster
Running wakeup_rt tracer
=> invoke_rcu_core
=> rcu_sched_clock_irq
=> update_process_times
=> tick_sched_handle
=> tick_sched_timer
=> __hrtimer_run_queues
=> hrtimer_interrupt
=> __sysvec_apic_timer_interrupt
=> asm_call_irq_on_stack
=> sysvec_apic_timer_interrupt
=> asm_sysvec_apic_timer_interrupt
=> lock_acquire
=> _raw_spin_lock
=> shmem_get_inode
=> shmem_mknod
=> lookup_open.isra.0
=> path_openat
=> do_filp_open
=> do_sys_openat2
=> __x64_sys_openat
=> do_syscall_64
=> entry_SYSCALL_64_after_hwframe
bash-1872 4dN.h5.. 31us : 0
bash-1872 4dN.h4.. 32us : task_woken_rt ←ttwu_do_wakeup
bash-1872 4dN..2.. 87us : put_prev_entity <-put_prev_task_fair
bash-1872 4dN..2.. 87us : update_curr <-put_prev_entity
bash-1872 4dN..2.. 87us : __update_load_avg_se <-update_load_avg
bash-1872 4dN..2.. 87us : __update_load_avg_cfs_rq <-update_load_avg
Running wakeup_rt tracer
bash-1872 4dN..2.. 87us : pick_next_task_stop <-__schedule
bash-1872 4dN..2.. 87us : pick_next_task_dl <-__schedule
bash-1872 4dN..2.. 87us : pick_next_task_rt <-__schedule
bash-1872 4dN..2.. 88us : update_rt_rq_load_avg <-pick_next_task_rt
bash-1872 4d...3.. 88us : __schedule
bash-1872 4d...3.. 88us : 1872:120:R ==> [004] 42: 98:R rcuc/4
bash-1872 4d...3.. 94us : <stack trace>
=> __ftrace_trace_stack
=> probe_wakeup_sched_switch
=> __schedule
=> preempt_schedule_common
=> preempt_schedule_thunk
=> _raw_spin_unlock
=> shmem_get_inode
=> shmem_mknod
=> lookup_open.isra.0
=> path_openat
=> do_filp_open
=> do_sys_openat2
=> __x64_sys_openat
=> do_syscall_64
=> entry_SYSCALL_64_after_hwframe
Interrupt off tracer
Task
Interrupt
Irqs disabled
latency
Irqs enabled
Running preemptirqsoff tracer
# trace-cmd start -p preemptirqsoff
# trace-cmd show
# tracer: preemptirqsoff
#
# preemptirqsoff latency trace v1.1.5 on 5.14.0-rc4-test+
# --------------------------------------------------------------------
# latency: 2325 us, #3005/3005, CPU#1 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:8)
# -----------------
# | task: bash-48651 (uid:0 nice:0 policy:0 rt_prio:0)
# -----------------
# => started at: _raw_spin_lock
# => ended at: _raw_spin_unlock
#
#
# _------=> CPU#
# / _-----=> irqs-off
# | / _----=> need-resched
# || / _---=> hardirq/softirq
# ||| / _--=> preempt-depth
# |||| / delay
# cmd pid ||||| time | caller
#  / |||||  | /
trace-cm-48651 1...1 0us : _raw_spin_lock
trace-cm-48651 1...1 1us : do_raw_spin_trylock <-_raw_spin_lock
trace-cm-48651 1...1 1us : flush_tlb_batched_pending <-unmap_page_range
trace-cm-48651 1...1 2us : vm_normal_page <-unmap_page_range
trace-cm-48651 1...1 2us : page_remove_rmap <-unmap_page_range

Recommended for you

qemu + gdb + sample_code: Run sample code in QEMU OS and observe Linux Kernel...
qemu + gdb + sample_code: Run sample code in QEMU OS and observe Linux Kernel...qemu + gdb + sample_code: Run sample code in QEMU OS and observe Linux Kernel...
qemu + gdb + sample_code: Run sample code in QEMU OS and observe Linux Kernel...

This document describes setting up a QEMU virtual machine with Ubuntu 20.04.1 to debug Linux kernel code using gdb. It has a 2-socket CPU configuration with 16GB of memory and disabled KASAN and ASLR. The QEMU VM can be used to run sample code and observe Linux kernel behavior under gdb, such as setting conditional breakpoints to analyze page fault behavior for mmap addresses by referencing a gdb debugging text file.

linux kernelgdbqemu
Delivering Docker & K3s worloads to IoT Edge devices
Delivering Docker & K3s worloads to IoT Edge devicesDelivering Docker & K3s worloads to IoT Edge devices
Delivering Docker & K3s worloads to IoT Edge devices

About 94% of AI Adopters are planning to use containers in the next 1 year. What’s driving this exponential growth? Faster time to deployment and Faster AI workload processing are the two major reasons. You can use GPUs in big data applications such as machine learning, data analytics, and genome sequencing. Docker containerization makes it easier for you to package and distribute applications. You can enable GPU support when using YARN on Docker containers. In this talk, I will demonstrate how Docker accelerates the AI workload development and deployment over the IoT Edge devices in efficient manner

nvidiadocker captain
How does PostgreSQL work with disks: a DBA's checklist in detail. PGConf.US 2015
How does PostgreSQL work with disks: a DBA's checklist in detail. PGConf.US 2015How does PostgreSQL work with disks: a DBA's checklist in detail. PGConf.US 2015
How does PostgreSQL work with disks: a DBA's checklist in detail. PGConf.US 2015

This document discusses how PostgreSQL works with disks and provides recommendations for disk subsystem monitoring, hardware selection, and configuration tuning to optimize performance. It explains that PostgreSQL relies on disk I/O for reading pages, writing the write-ahead log (WAL), and checkpointing. It recommends monitoring disk utilization, IOPS, latency, and I/O wait. The document also provides tips for choosing hardware like SSDs or RAID configurations and configuring the operating system, file systems, and PostgreSQL to improve performance.

postgresql
Running preemptirqsoff tracer
[...]
trace-cm-48651 1...1 2313us : unlock_page_memcg <-unmap_page_range
trace-cm-48651 1...1 2314us : __rcu_read_unlock <-unlock_page_memcg
trace-cm-48651 1...1 2315us : __tlb_remove_page_size <-unmap_page_range
trace-cm-48651 1...1 2316us : vm_normal_page <-unmap_page_range
trace-cm-48651 1...1 2317us : page_remove_rmap <-unmap_page_range
trace-cm-48651 1...1 2318us : lock_page_memcg <-page_remove_rmap
trace-cm-48651 1...1 2318us : __rcu_read_lock <-lock_page_memcg
trace-cm-48651 1...1 2319us : unlock_page_memcg <-unmap_page_range
trace-cm-48651 1...1 2320us : __rcu_read_unlock <-unlock_page_memcg
trace-cm-48651 1...1 2321us : __tlb_remove_page_size <-unmap_page_range
trace-cm-48651 1...1 2322us : _raw_spin_unlock <-unmap_page_range
trace-cm-48651 1...1 2323us : do_raw_spin_unlock <-_raw_spin_unlock
trace-cm-48651 1...1 2324us : preempt_count_sub <-_raw_spin_unlock
trace-cm-48651 1...1 2325us : _raw_spin_unlock
trace-cm-48651 1...1 2327us+: tracer_preempt_on <-_raw_spin_unlock
trace-cm-48651 1...1 2343us : <stack trace>
=> unmap_page_range
=> unmap_vmas
=> exit_mmap
=> mmput
=> begin_new_exec
=> load_elf_binary
=> bprm_execve
=> do_execveat_common
=> __x64_sys_execve
=> do_syscall_64
=> entry_SYSCALL_64_after_hwframe
Running preemptirqsoff tracer
# trace-cmd start -p preemptirqsoff -d -O sym-offset
# trace-cmd show
# tracer: preemptirqsoff
[..]
# latency: 248 us, #4/4, CPU#6 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:8)
# -----------------
# | task: ksoftirqd/6-47 (uid:0 nice:0 policy:0 rt_prio:0)
# -----------------
# => started at: run_ksoftirqd
# => ended at: run_ksoftirqd
[..]
# cmd pid ||||| time | caller
#  / |||||  | /
<idle>-0 4d..1 1us!: cpuidle_enter_state+0xcf/0x410
kworker/-48096 4...1 242us : schedule+0x4d/0xe0 <-schedule+0x4d/0xe0
kworker/-48096 4...1 243us : tracer_preempt_on+0xf4/0x110 <-schedule+0x4d/0xe0
kworker/-48096 4...1 248us : <stack trace>
=> worker_thread+0xd4/0x3c0
=> kthread+0x155/0x180
=> ret_from_fork+0x22/0x30
Measuring Interrupt Latency
Task
Interrupt
latency
Measuring latency from interrupts
●
You can easily trace the latency from interrupts
– For x86:
# trace-cmd record -p function_graph -l handle_irq_event 
-l ‘*sysvec_*’ -e irq_handler_entry 
-e 'irq_vectors:*entry*'

Recommended for you

Java Performance Analysis on Linux with Flame Graphs
Java Performance Analysis on Linux with Flame GraphsJava Performance Analysis on Linux with Flame Graphs
Java Performance Analysis on Linux with Flame Graphs

This document discusses using Linux perf_events (perf) profiling tools to analyze Java performance on Linux. It describes how perf can provide complete visibility into Java, JVM, GC and system code but that Java profilers have limitations. It presents the solution of using perf to collect mixed-mode flame graphs that include Java method names and symbols. It also discusses fixing issues with broken Java stacks and missing symbols on x86 architectures in perf profiles.

javaperformance
Kernel Recipes 2017 - Understanding the Linux kernel via ftrace - Steven Rostedt
Kernel Recipes 2017 - Understanding the Linux kernel via ftrace - Steven RostedtKernel Recipes 2017 - Understanding the Linux kernel via ftrace - Steven Rostedt
Kernel Recipes 2017 - Understanding the Linux kernel via ftrace - Steven Rostedt

Ftrace is the official tracer of the Linux kernel. It has been apart of Linux since 2.6.31, and has grown tremendously ever since. Ftrace’s name comes from its most powerful feature: function tracing. But the ftrace infrastructure is much more than that. It also encompasses the trace events that are used by perf, as well as kprobes that can dynamically add trace events that the user defines. This talk will focus on learning how the kernel works by using the ftrace infrastructure. It will show how to see what happens within the kernel during a system call; learn how interrupts work; see how ones processes are being scheduled, and more. A quick introduction to some tools like trace-cmd and KernelShark will also be demonstrated. Steven Rostedt, VMware

linux kernelftrace
Linux 4.x Tracing Tools: Using BPF Superpowers
Linux 4.x Tracing Tools: Using BPF SuperpowersLinux 4.x Tracing Tools: Using BPF Superpowers
Linux 4.x Tracing Tools: Using BPF Superpowers

Talk for USENIX LISA 2016 by Brendan Gregg. "Linux 4.x Tracing Tools: Using BPF Superpowers The Linux 4.x series heralds a new era of Linux performance analysis, with the long-awaited integration of a programmable tracer: Enhanced BPF (eBPF). Formally the Berkeley Packet Filter, BPF has been enhanced in Linux to provide system tracing capabilities, and integrates with dynamic tracing (kprobes and uprobes) and static tracing (tracepoints and USDT). This has allowed dozens of new observability tools to be developed so far: for example, measuring latency distributions for file system I/O and run queue latency, printing details of storage device I/O and TCP retransmits, investigating blocked stack traces and memory leaks, and a whole lot more. These lead to performance wins large and small, especially when instrumenting areas that previously had zero visibility. Tracing superpowers have finally arrived. In this talk I'll show you how to use BPF in the Linux 4.x series, and I'll summarize the different tools and front ends available, with a focus on iovisor bcc. bcc is an open source project to provide a Python front end for BPF, and comes with dozens of new observability tools (many of which I developed). These tools include new BPF versions of old classics, and many new tools, including: execsnoop, opensnoop, funccount, trace, biosnoop, bitesize, ext4slower, ext4dist, tcpconnect, tcpretrans, runqlat, offcputime, offwaketime, and many more. I'll also summarize use cases and some long-standing issues that can now be solved, and how we are using these capabilities at Netflix."

linux performance tracinglinuxperformance
Tracing Latency from Interrupts
# trace-cmd report -l --cpu 2
sleep-2513 [002] 2973.197184: funcgraph_entry: | __sysvec_apic_timer_interrupt() {
sleep-2513 [002] 2973.197186: local_timer_entry: vector=236
sleep-2513 [002] 2973.197196: funcgraph_exit: + 12.233 us | }
sleep-2513 [002] 2973.197206: funcgraph_entry: | __sysvec_irq_work() {
sleep-2513 [002] 2973.197207: irq_work_entry: vector=246
sleep-2513 [002] 2973.197207: funcgraph_exit: 1.405 us | }
<idle>-0 [002] 2973.198186: funcgraph_entry: | __sysvec_apic_timer_interrupt() {
<idle>-0 [002] 2973.198187: local_timer_entry: vector=236
<idle>-0 [002] 2973.198193: funcgraph_exit: 7.992 us | }
<idle>-0 [002] 2974.991721: funcgraph_entry: | handle_irq_event() {
<idle>-0 [002] 2974.991723: irq_handler_entry: irq=24 name=ahci[0000:00:1f.2]
<idle>-0 [002] 2974.991733: funcgraph_exit: + 13.158 us | }
<idle>-0 [002] 2977.039843: funcgraph_entry: | handle_irq_event() {
<idle>-0 [002] 2977.039845: irq_handler_entry: irq=24 name=ahci[0000:00:1f.2]
<idle>-0 [002] 2977.039855: funcgraph_exit: + 12.869 us | }
Problems with the latency tracers
●
No control over what tasks they trace
– They trace the highest priority process
– May not be the process you are interested in
●
Not flexible
– Has one use case
– General for the entire system
Tracing interrupt latency with function graph tracer
●
Does not have a “max latency”
– You see all the latency in a trace
– No way to record the max latency found
Introducing Synthetic Events
●
Can map two events into a single event

Recommended for you

Patroni - HA PostgreSQL made easy
Patroni - HA PostgreSQL made easyPatroni - HA PostgreSQL made easy
Patroni - HA PostgreSQL made easy

This document discusses Patroni, an open-source tool for managing high availability PostgreSQL clusters. It describes how Patroni uses a distributed configuration system like Etcd or Zookeeper to provide automated failover for PostgreSQL databases. Key features of Patroni include manual and scheduled failover, synchronous replication, dynamic configuration updates, and integration with backup tools like WAL-E. The document also covers some of the challenges of building automatic failover systems and how Patroni addresses issues like choosing a new master node and reattaching failed nodes.

zalandozookeeperhigh-availability
PostgreSQL Streaming Replication Cheatsheet
PostgreSQL Streaming Replication CheatsheetPostgreSQL Streaming Replication Cheatsheet
PostgreSQL Streaming Replication Cheatsheet

The document provides configuration instructions and guidelines for setting up streaming replication between a PostgreSQL master and standby server, including setting parameter values for wal_level, max_wal_senders, wal_keep_segments, creating a dedicated replication role, using pg_basebackup to initialize the standby, and various recovery target options to control the standby's behavior. It also discusses synchronous replication using replication slots and monitoring the replication process on both the master and standby servers.

postgresql databases
Using Optimizer Hints to Improve MySQL Query Performance
Using Optimizer Hints to Improve MySQL Query PerformanceUsing Optimizer Hints to Improve MySQL Query Performance
Using Optimizer Hints to Improve MySQL Query Performance

The document discusses using optimizer hints in MySQL to improve query performance. It covers index hints to influence which indexes the optimizer uses, join order hints to control join order, and subquery hints. New optimizer hints introduced in MySQL 5.7 and 8.0 are also presented, including hints for join strategies, materialized intermediate results, and query block naming. Examples are provided to illustrate how hints can be used and their behavior.

mysql optimizer hints
Introducing Synthetic Events
●
Can map two events into a single event
– sched_waking + sched_switch wakeup_latency
→
– irqs_disabled + irqs_enabled irqs_off_latency
→
– irq_enter_handler + irq_exit_handler irq_latency
→
Introducing Synthetic Events
●
Can map two events into a single event
– sched_waking + sched_switch wakeup_latency
→
– irqs_disabled + irqs_enabled irqs_off_latency
→
– irq_enter_handler + irq_exit_handler irq_latency
→
●
Have all the functionality as a normal event
Introducing Synthetic Events
●
Can map two events into a single event
– sched_waking + sched_switch wakeup_latency
→
– irqs_disabled + irqs_enabled irqs_off_latency
→
– irq_enter_handler + irq_exit_handler irq_latency
→
●
Have all the functionality as a normal event
– Can be filtered on
Introducing Synthetic Events
●
Can map two events into a single event
– sched_waking + sched_switch wakeup_latency
→
– irqs_disabled + irqs_enabled irqs_off_latency
→
– irq_enter_handler + irq_exit_handler irq_latency
→
●
Have all the functionality as a normal event
– Can be filtered on
– Can have triggers attached (like histograms)

Recommended for you

Linux 4.x Tracing: Performance Analysis with bcc/BPF
Linux 4.x Tracing: Performance Analysis with bcc/BPFLinux 4.x Tracing: Performance Analysis with bcc/BPF
Linux 4.x Tracing: Performance Analysis with bcc/BPF

Talk about bcc/eBPF for SCALE15x (2017) by Brendan Gregg. "BPF (Berkeley Packet Filter) has been enhanced in the Linux 4.x series and now powers a large collection of performance analysis and observability tools ready for you to use, included in the bcc (BPF Complier Collection) open source project. BPF nowadays can do system tracing, software defined networks, and kernel fast path: much more than just filtering packets! This talk will focus on the bcc/BPF tools for performance analysis, which make use of other built in Linux capabilities: dynamic tracing (kprobes and uprobes) and static tracing (tracepoints and USDT). There are now bcc tools for measuring latency distributions for file system I/O and run queue latency, printing details of storage device I/O and TCP retransmits, investigating blocked stack traces and memory leaks, and a whole lot more. These lead to performance wins large and small, especially when instrumenting areas that previously had zero visibility. Tracing superpowers have finally arrived, built in to Linux."

linux performance tracingebpfperformance
Process Scheduler and Balancer in Linux Kernel
Process Scheduler and Balancer in Linux KernelProcess Scheduler and Balancer in Linux Kernel
Process Scheduler and Balancer in Linux Kernel

The document discusses process scheduling in the Linux kernel. It begins with an introduction to schedulers and outlines Linux scheduler history, including round-robin, O(N), O(1), and Completely Fair schedulers. It then provides more details on the Completely Fair Scheduler's use of virtual runtime to determine process execution order and maintain fairness. The document also briefly discusses the real-time scheduler and key data structures used for scheduling like task_struct and sched_domain. It concludes with an overview of the CFS load balancer's hierarchical design and methods used to balance tasks among CPU cores.

scheduler; load balance; linux kernel; process man
Performance Schema for MySQL Troubleshooting
Performance Schema for MySQL TroubleshootingPerformance Schema for MySQL Troubleshooting
Performance Schema for MySQL Troubleshooting

The Performance Schema provides detailed information for troubleshooting and optimizing MySQL. It collects instrumentation data on server operations, statements, memory usage, locks and connections. The data can be used to identify slow queries, statements not using indexes, memory consumption trends over time, and more. Configuration and enabling specific instruments allows controlling the level of detail collected.

performancemysqlperformance schema
Synthetic events
# echo 'wakeup_lat s32 pid; u64 delta;' > /sys/kernel/tracing/synthetic_events
# echo 'hist:keys=pid:__arg__1=pid,__arg__2=common_timestamp.usecs' > 
/sys/kernel/tracing/events/sched/sched_waking/trigger
# echo 'hist:keys=next_pid:pid=$__arg__1,’
‘delta=common_timestamp.usecs-$__arg__2:onmatch(sched.sched_waking)’
‘.trace(wakeup_lat,$pid,$delta) if next_comm == “cyclictest”' > 
/sys/kernel/tracing/events/sched/sched_switch/trigger
Synthetic events
# echo 'wakeup_lat s32 pid; u64 delta;' > /sys/kernel/tracing/synthetic_events
# echo 'hist:keys=pid:__arg__1=pid,__arg__2=common_timestamp.usecs' > 
/sys/kernel/tracing/events/sched/sched_waking/trigger
# echo 'hist:keys=next_pid:pid=$__arg__1,’
‘delta=common_timestamp.usecs-$__arg__2:onmatch(sched.sched_waking)’
‘.trace(wakeup_lat,$pid,$delta) if next_comm == “cyclictest”' > 
/sys/kernel/tracing/events/sched/sched_switch/trigger
Too Complex!
Introducing libtracefs
A library to interact with the tracefs file system
All functions have man pages
The tracefs_sql man page has the sqlhist program in it
https://git.kernel.org/pub/scm/libs/libtrace/libtracefs.git/
git clone git://git.kernel.org/pub/scm/libs/libtrace/libtracefs.git
cd libtracefs
make sqlhist # builds from the man page!
Synthetic events
# sqlhist -e -n wakeup_lat 
‘SELECT start.pid, (end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS delta FROM ’ 
‘sched_waking AS start JOIN sched_switch AS end ON start.pid = end.next_pid' 
‘WHERE end.next_pid = “cyclictest”’

Recommended for you

Percona Live UK 2014 Part III
Percona Live UK 2014  Part IIIPercona Live UK 2014  Part III
Percona Live UK 2014 Part III

The document discusses diagnosing and mitigating MySQL performance issues. It describes using various operating system monitoring tools like vmstat, iostat, and top to analyze CPU, memory, disk, and network utilization. It also discusses using MySQL-specific tools like the MySQL command line, mysqladmin, mysqlbinlog, and external tools to diagnose issues like high load, I/O wait, or slow queries by examining metrics like queries, connections, storage engine statistics, and InnoDB logs and data written. The agenda covers identifying system and MySQL-specific bottlenecks by verifying OS metrics and running diagnostics on the database, storage engines, configuration, and queries.

mysql
Kernel Recipes 2019 - ftrace: Where modifying a running kernel all started
Kernel Recipes 2019 - ftrace: Where modifying a running kernel all startedKernel Recipes 2019 - ftrace: Where modifying a running kernel all started
Kernel Recipes 2019 - ftrace: Where modifying a running kernel all started

The document describes the ftrace function tracing tool in Linux kernels. It allows attaching to functions in the kernel to trace function calls. It works by having the GCC compiler insert indirect function entry calls. These calls are recorded during linking and replaced with nops at boot time for efficiency. This allows function tracing with low overhead by tracing the indirect function entry calls.

linux kernelopen source
OSDC 2017 - Werner Fischer - Linux performance profiling and monitoring
OSDC 2017 - Werner Fischer - Linux performance profiling and monitoringOSDC 2017 - Werner Fischer - Linux performance profiling and monitoring
OSDC 2017 - Werner Fischer - Linux performance profiling and monitoring

Nowadays system administrators have great choices when it comes down to Linux performance profiling and monitoring. The challenge is to pick the appropriate tools and interpret their results correctly. This talk is a chance to take a tour through various performance profiling and benchmarking tools, focusing on their benefit for every sysadmin. More than 25 different tools are presented. Ranging from well known tools like strace, iostat, tcpdump or vmstat to new features like Linux tracepoints or perf_events. You will also learn which tools can be monitored by Icinga and which monitoring plugins are already available for that. At the end the goal is to gather reference points to look at, whenever you are faced with performance problems. Take the chance to close your knowledge gaps and learn how to get the most out of your system.

osdc 2017
Synthetic events
# sqlhist -e -n wakeup_lat 
‘SELECT start.pid, (end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS delta FROM ’ 
‘sched_waking AS start JOIN sched_switch AS end ON start.pid = end.next_pid' 
‘WHERE end.next_pid = “cyclictest”’
Synthetic events
# sqlhist -e -n wakeup_lat 
‘SELECT start.pid, (end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS delta FROM ’ 
‘sched_waking AS start JOIN sched_switch AS end ON start.pid = end.next_pid' 
‘WHERE end.next_pid = “cyclictest”’
Synthetic events
# sqlhist -e -n wakeup_lat 
‘SELECT start.pid, (end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS delta FROM ’ 
‘sched_waking AS start JOIN sched_switch AS end ON start.pid = end.next_pid' 
‘WHERE end.next_pid = “cyclictest”’
Synthetic events
# sqlhist -e -n wakeup_lat 
‘SELECT start.pid, (end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS delta FROM ’ 
‘sched_waking AS start JOIN sched_switch AS end ON start.pid = end.next_pid' 
‘WHERE end.next_pid = “cyclictest”’

Recommended for you

Interruption Timer Périodique
Interruption Timer PériodiqueInterruption Timer Périodique
Interruption Timer Périodique

Ftrace is a kernel tracing tool that uses a ring buffer to record trace events from various tracers like function, syscall, and graph tracers. It provides a unified interface for low-level kernel tracing via tracepoints and a ring buffer that tracers can write to. Tracers instrument different parts of the kernel like functions or syscalls and format trace events that are inserted into the ring buffer. Ftrace also supports higher-level trace events that can be filtered and toggled on or off.

kernelred hattimer
Kernel Recipes 2017: Performance Analysis with BPF
Kernel Recipes 2017: Performance Analysis with BPFKernel Recipes 2017: Performance Analysis with BPF
Kernel Recipes 2017: Performance Analysis with BPF

Talk by Brendan Gregg at Kernel Recipes 2017 (Paris): "The in-kernel Berkeley Packet Filter (BPF) has been enhanced in recent kernels to do much more than just filtering packets. It can now run user-defined programs on events, such as on tracepoints, kprobes, uprobes, and perf_events, allowing advanced performance analysis tools to be created. These can be used in production as the BPF virtual machine is sandboxed and will reject unsafe code, and are already in use at Netflix. Beginning with the bpf() syscall in 3.18, enhancements have been added in many kernel versions since, with major features for BPF analysis landing in Linux 4.1, 4.4, 4.7, and 4.9. Specific capabilities these provide include custom in-kernel summaries of metrics, custom latency measurements, and frequency counting kernel and user stack traces on events. One interesting case involves saving stack traces on wake up events, and associating them with the blocked stack trace: so that we can see the blocking stack trace and the waker together, merged in kernel by a BPF program (that particular example is in the kernel as samples/bpf/offwaketime). This talk will discuss the new BPF capabilities for performance analysis and debugging, and demonstrate the new open source tools that have been developed to use it, many of which are in the Linux Foundation iovisor bcc (BPF Compiler Collection) project. These include tools to analyze the CPU scheduler, TCP performance, file system performance, block I/O, and more."

bpflinuxlinux performance tracing
Kernel Recipes 2017 - Performance analysis Superpowers with Linux BPF - Brend...
Kernel Recipes 2017 - Performance analysis Superpowers with Linux BPF - Brend...Kernel Recipes 2017 - Performance analysis Superpowers with Linux BPF - Brend...
Kernel Recipes 2017 - Performance analysis Superpowers with Linux BPF - Brend...

The in-kernel Berkeley Packet Filter (BPF) has been enhanced in recent kernels to do much more than just filtering packets. It can now run user-defined programs on events, such as on tracepoints, kprobes, uprobes, and perf_events, allowing advanced performance analysis tools to be created. These can be used in production as the BPF virtual machine is sandboxed and will reject unsafe code, and are already in use at Netflix. Beginning with the bpf() syscall in 3.18, enhancements have been added in many kernel versions since, with major features for BPF analysis landing in Linux 4.1, 4.4, 4.7, and 4.9. Specific capabilities these provide include custom in-kernel summaries of metrics, custom latency measurements, and frequency counting kernel and user stack traces on events. One interesting case involves saving stack traces on wake up events, and associating them with the blocked stack trace: so that we can see the blocking stack trace and the waker together, merged in kernel by a BPF program (that particular example is in the kernel as samples/bpf/offwaketime). This talk will discuss the new BPF capabilities for performance analysis and debugging, and demonstrate the new open source tools that have been developed to use it, many of which are in the Linux Foundation iovisor bcc (BPF Compiler Collection) project. These include tools to analyze the CPU scheduler, TCP performance, file system performance, block I/O, and more. Brendan Gregg, Netflix

linux kernelperformanceoptimization
Synthetic events
# sqlhist -e -n wakeup_lat 
‘SELECT start.pid, (end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS delta FROM ’ 
‘sched_waking AS start JOIN sched_switch AS end ON start.pid = end.next_pid' 
‘WHERE end.next_pid = “cyclictest”’
Synthetic events
# sqlhist -e -n wakeup_lat 
‘SELECT start.pid, (end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS delta FROM ’ 
‘sched_waking AS start JOIN sched_switch AS end ON start.pid = end.next_pid' 
‘WHERE end.next_pid = “cyclictest”’
Synthetic events
# sqlhist -e -n wakeup_lat 
‘SELECT start.pid, (end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS delta FROM ’ 
‘sched_waking AS start JOIN sched_switch AS end ON start.pid = end.next_pid' 
‘WHERE end.next_pid = “cyclictest”’
Synthetic events
# sqlhist -e -n wakeup_lat 
‘SELECT start.pid, (end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS delta FROM ’ 
‘sched_waking AS start JOIN sched_switch AS end ON start.pid = end.next_pid' 
‘WHERE end.next_pid = “cyclictest”’

Recommended for you

pg_proctab: Accessing System Stats in PostgreSQL
pg_proctab: Accessing System Stats in PostgreSQLpg_proctab: Accessing System Stats in PostgreSQL
pg_proctab: Accessing System Stats in PostgreSQL

pg_proctab is a collection of PostgreSQL stored functions that provide access to the operating system process table using SQL. We'll show you which functions are available and where they collect the data, and give examples of their use to collect processor and I/O statistics on SQL queries. These stored functions currently only work on Linux-based systems.

postgresql
pg_proctab: Accessing System Stats in PostgreSQL
pg_proctab: Accessing System Stats in PostgreSQLpg_proctab: Accessing System Stats in PostgreSQL
pg_proctab: Accessing System Stats in PostgreSQL

The document discusses using pg_proctab, a PostgreSQL extension that provides functions to query operating system process and statistics tables from within PostgreSQL. It demonstrates how to use pg_proctab to monitor CPU and memory usage, I/O, and other process-level metrics for queries. The document also shows how to generate custom reports on database activity and performance by taking snapshots before and after queries and analyzing the differences.

OSSNA 2017 Performance Analysis Superpowers with Linux BPF
OSSNA 2017 Performance Analysis Superpowers with Linux BPFOSSNA 2017 Performance Analysis Superpowers with Linux BPF
OSSNA 2017 Performance Analysis Superpowers with Linux BPF

Talk by Brendan Gregg for OSSNA 2017. "Advanced performance observability and debugging have arrived built into the Linux 4.x series, thanks to enhancements to Berkeley Packet Filter (BPF, or eBPF) and the repurposing of its sandboxed virtual machine to provide programmatic capabilities to system tracing. Netflix has been investigating its use for new observability tools, monitoring, security uses, and more. This talk will be a dive deep on these new tracing, observability, and debugging capabilities, which sooner or later will be available to everyone who uses Linux. Whether you’re doing analysis over an ssh session, or via a monitoring GUI, BPF can be used to provide an efficient, custom, and deep level of detail into system and application performance. This talk will also demonstrate the new open source tools that have been developed, which make use of kernel- and user-level dynamic tracing (kprobes and uprobes), and kernel- and user-level static tracing (tracepoints). These tools provide new insights for file system and storage performance, CPU scheduler performance, TCP performance, and a whole lot more. This is a major turning point for Linux systems engineering, as custom advanced performance instrumentation can be used safely in production environments, powering a new generation of tools and visualizations."

linuxebpfbpf
cyclictest
A tool used by real-time developers to test wake up latency in the system
https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git/
git clone git://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
cd rt-tests
make cyclictest
Customize latency tracing
# sqlhist -e -n wakeup_lat -T -m lat 'SELECT end.next_comm AS comm, ’ 
‘(end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS lat ’ 
‘FROM sched_waking AS start JOIN sched_switch AS end ’ 
‘ON start.pid = end.next_pid’ 
‘WHERE end.next_prio < 100 && end.next_comm == "cyclictest"'
# trace-cmd start -e all -e wakeup_lat -R stacktrace
# cyclictest -l 1000 -p80 -i250 -a -t -q -m -d 0 -b 1000 --tracemark
# trace-cmd show -s | tail -16
<idle>-0 [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1
<idle>-0 [002] d..2 23454.902254: sched_switch: prev_comm=swapper/2 prev_pid=0 prev_prio=120
prev_state=R ==> next_comm=cyclictest next_pid=12275 next_prio=19
<idle>-0 [002] d..4 23454.902256: wakeup_lat: next_comm=cyclictest lat=17
<idle>-0 [002] d..5 23454.902258: <stack trace>
=> trace_event_raw_event_synth
=> action_trace
=> event_hist_trigger
=> event_triggers_call
=> trace_event_buffer_commit
=> trace_event_raw_event_sched_switch
=> __traceiter_sched_switch
=> __schedule
=> schedule_idle
=> do_idle
=> cpu_startup_entry
=> secondary_startup_64_no_verify
Customize latency tracing
# sqlhist -e -n wakeup_lat -T -m lat 'SELECT end.next_comm AS comm, ’ 
‘(end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS lat ’ 
‘FROM sched_waking AS start JOIN sched_switch AS end ’ 
‘ON start.pid = end.next_pid’ 
‘WHERE end.next_prio < 100 && end.next_comm == "cyclictest"'
# trace-cmd start -e all -e wakeup_lat -R stacktrace
# cyclictest -l 1000 -p80 -i250 -a -t -q -m -d 0 -b 1000 --tracemark
# trace-cmd show -s | tail -16
<idle>-0 [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1
<idle>-0 [002] d..2 23454.902254: sched_switch: prev_comm=swapper/2 prev_pid=0 prev_prio=120
prev_state=R ==> next_comm=cyclictest next_pid=12275 next_prio=19
<idle>-0 [002] d..4 23454.902256: wakeup_lat: next_comm=cyclictest lat=17
<idle>-0 [002] d..5 23454.902258: <stack trace>
=> trace_event_raw_event_synth
=> action_trace
=> event_hist_trigger
=> event_triggers_call
=> trace_event_buffer_commit
=> trace_event_raw_event_sched_switch
=> __traceiter_sched_switch
=> __schedule
=> schedule_idle
=> do_idle
=> cpu_startup_entry
=> secondary_startup_64_no_verify
Customize latency tracing
# sqlhist -e -n wakeup_lat -T -m lat 'SELECT end.next_comm AS comm, ’ 
‘(end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS lat ’ 
‘FROM sched_waking AS start JOIN sched_switch AS end ’ 
‘ON start.pid = end.next_pid’ 
‘WHERE end.next_prio < 100 && end.next_comm == "cyclictest"'
# trace-cmd start -e all -e wakeup_lat -R stacktrace
# cyclictest -l 1000 -p80 -i250 -a -t -q -m -d 0 -b 1000 --tracemark
# trace-cmd show -s | tail -16
<idle>-0 [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1
<idle>-0 [002] d..2 23454.902254: sched_switch: prev_comm=swapper/2 prev_pid=0 prev_prio=120
prev_state=R ==> next_comm=cyclictest next_pid=12275 next_prio=19
<idle>-0 [002] d..4 23454.902256: wakeup_lat: next_comm=cyclictest lat=17
<idle>-0 [002] d..5 23454.902258: <stack trace>
=> trace_event_raw_event_synth
=> action_trace
=> event_hist_trigger
=> event_triggers_call
=> trace_event_buffer_commit
=> trace_event_raw_event_sched_switch
=> __traceiter_sched_switch
=> __schedule
=> schedule_idle
=> do_idle
=> cpu_startup_entry
=> secondary_startup_64_no_verify

Recommended for you

EKON22 Introduction to Machinelearning
EKON22 Introduction to MachinelearningEKON22 Introduction to Machinelearning
EKON22 Introduction to Machinelearning

In this session Max Kleiner shows four groups of the ML: Regression, Dimension Reduction, Clustering and Classification. ML recognizes patterns and laws in the learning data. Most ML projects allegedly fail due to lack of data consolidation and due to lack of hypothesis. On the basis of the well-known IRIS dataset the 4 groups with 4 algorithms each are gone through and this lack is avoided.

machine learningdata sciencepython
bcc/BPF tools - Strategy, current tools, future challenges
bcc/BPF tools - Strategy, current tools, future challengesbcc/BPF tools - Strategy, current tools, future challenges
bcc/BPF tools - Strategy, current tools, future challenges

Brendan Gregg discusses the current state and future potential of BPF and BCC tools for observability in Linux. He outlines 18 areas where BPF support has progressed and 16 areas still needing work. Gregg also discusses challenges like dynamic tracing stability, overhead, ease of coding, and developing visualizations. He proposes finishing ports of his old DTrace tools and links to resources on BPF, BCC, and flame graphs.

io visor summitlinuxlinux foundation
BPF Tools 2017
BPF Tools 2017BPF Tools 2017
BPF Tools 2017

Slides from a discussion at the IOVisor workshop in Feb 2017, about BPF performance and observability tools.

bpfebpf
Customize latency tracing
# sqlhist -e -n wakeup_lat -T -m lat 'SELECT end.next_comm AS comm, ’ 
‘(end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS lat ’ 
‘FROM sched_waking AS start JOIN sched_switch AS end ’ 
‘ON start.pid = end.next_pid’ 
‘WHERE end.next_prio < 100 && end.next_comm == "cyclictest"'
# trace-cmd start -e all -e wakeup_lat -R stacktrace
# cyclictest -l 1000 -p80 -i250 -a -t -q -m -d 0 -b 1000 --tracemark
# trace-cmd show -s | tail -16
<idle>-0 [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1
<idle>-0 [002] d..2 23454.902254: sched_switch: prev_comm=swapper/2 prev_pid=0 prev_prio=120
prev_state=R ==> next_comm=cyclictest next_pid=12275 next_prio=19
<idle>-0 [002] d..4 23454.902256: wakeup_lat: next_comm=cyclictest lat=17
<idle>-0 [002] d..5 23454.902258: <stack trace>
=> trace_event_raw_event_synth
=> action_trace
=> event_hist_trigger
=> event_triggers_call
=> trace_event_buffer_commit
=> trace_event_raw_event_sched_switch
=> __traceiter_sched_switch
=> __schedule
=> schedule_idle
=> do_idle
=> cpu_startup_entry
=> secondary_startup_64_no_verify
Customize latency tracing
# sqlhist -e -n wakeup_lat -T -m lat 'SELECT end.next_comm AS comm, ’ 
‘(end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS lat ’ 
‘FROM sched_waking AS start JOIN sched_switch AS end ’ 
‘ON start.pid = end.next_pid’ 
‘WHERE end.next_prio < 100 && end.next_comm == "cyclictest"'
# trace-cmd start -e all -e wakeup_lat -R stacktrace
# cyclictest -l 1000 -p80 -i250 -a -t -q -m -d 0 -b 1000 --tracemark
# trace-cmd show -s | tail -16
<idle>-0 [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1
<idle>-0 [002] d..2 23454.902254: sched_switch: prev_comm=swapper/2 prev_pid=0 prev_prio=120
prev_state=R ==> next_comm=cyclictest next_pid=12275 next_prio=19
<idle>-0 [002] d..4 23454.902256: wakeup_lat: next_comm=cyclictest lat=17
<idle>-0 [002] d..5 23454.902258: <stack trace>
=> trace_event_raw_event_synth
=> action_trace
=> event_hist_trigger
=> event_triggers_call
=> trace_event_buffer_commit
=> trace_event_raw_event_sched_switch
=> __traceiter_sched_switch
=> __schedule
=> schedule_idle
=> do_idle
=> cpu_startup_entry
=> secondary_startup_64_no_verify
Customize latency tracing
# sqlhist -e -n wakeup_lat -T -m lat 'SELECT end.next_comm AS comm, ’ 
‘(end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS lat ’ 
‘FROM sched_waking AS start JOIN sched_switch AS end ’ 
‘ON start.pid = end.next_pid’ 
‘WHERE end.next_prio < 100 && end.next_comm == "cyclictest"'
# trace-cmd start -e all -e wakeup_lat -R stacktrace
# cyclictest -l 1000 -p80 -i250 -a -t -q -m -d 0 -b 1000 --tracemark
# trace-cmd show -s | tail -16
<idle>-0 [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1
<idle>-0 [002] d..2 23454.902254: sched_switch: prev_comm=swapper/2 prev_pid=0 prev_prio=120
prev_state=R ==> next_comm=cyclictest next_pid=12275 next_prio=19
<idle>-0 [002] d..4 23454.902256: wakeup_lat: next_comm=cyclictest lat=17
<idle>-0 [002] d..5 23454.902258: <stack trace>
=> trace_event_raw_event_synth
=> action_trace
=> event_hist_trigger
=> event_triggers_call
=> trace_event_buffer_commit
=> trace_event_raw_event_sched_switch
=> __traceiter_sched_switch
=> __schedule
=> schedule_idle
=> do_idle
=> cpu_startup_entry
=> secondary_startup_64_no_verify
Customize latency tracing
# sqlhist -e -n wakeup_lat -T -m lat 'SELECT end.next_comm AS comm, ’ 
‘(end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS lat ’ 
‘FROM sched_waking AS start JOIN sched_switch AS end ’ 
‘ON start.pid = end.next_pid’ 
‘WHERE end.next_prio < 100 && end.next_comm == "cyclictest"'
# trace-cmd start -e all -e wakeup_lat -R stacktrace
# cyclictest -l 1000 -p80 -i250 -a -t -q -m -d 0 -b 1000 --tracemark
# trace-cmd show -s | tail -16
<idle>-0 [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1
<idle>-0 [002] d..2 23454.902254: sched_switch: prev_comm=swapper/2 prev_pid=0 prev_prio=120
prev_state=R ==> next_comm=cyclictest next_pid=12275 next_prio=19
<idle>-0 [002] d..4 23454.902256: wakeup_lat: next_comm=cyclictest lat=17
<idle>-0 [002] d..5 23454.902258: <stack trace>
=> trace_event_raw_event_synth
=> action_trace
=> event_hist_trigger
=> event_triggers_call
=> trace_event_buffer_commit
=> trace_event_raw_event_sched_switch
=> __traceiter_sched_switch
=> __schedule
=> schedule_idle
=> do_idle
=> cpu_startup_entry
=> secondary_startup_64_no_verify

Recommended for you

Debugging linux issues with eBPF
Debugging linux issues with eBPFDebugging linux issues with eBPF
Debugging linux issues with eBPF

Presented at LISA18: https://www.usenix.org/conference/lisa18/presentation/babrou This is a technical dive into how we used eBPF to solve real-world issues uncovered during an innocent OS upgrade. We'll see how we debugged 10x CPU increase in Kafka after Debian upgrade and what lessons we learned. We'll get from high-level effects like increased CPU to flamegraphs showing us where the problem lies to tracing timers and functions calls in the Linux kernel. The focus is on tools what operational engineers can use to debug performance issues in production. This particular issue happened at Cloudflare on a Kafka cluster doing 100Gbps of ingress and many multiple of that egress.

ebpflinux
ANALYZE for executable statements - a new way to do optimizer troubleshooting...
ANALYZE for executable statements - a new way to do optimizer troubleshooting...ANALYZE for executable statements - a new way to do optimizer troubleshooting...
ANALYZE for executable statements - a new way to do optimizer troubleshooting...

"ANALYZE for executable statements - a new way to do optimizer troubleshooting in MariaDB 10.1" session from Percona Live Santa Clara 2015

mariadbexplainmysql
Perf Tuning Short
Perf Tuning ShortPerf Tuning Short
Perf Tuning Short

The document provides an overview of how to summarize and interpret information from MySQL server status and variable outputs to understand server performance and optimize configuration. It explains that status variables show current server activity levels, while global and session variables display configuration settings. Comparing status outputs over time calculates rates like queries/second. Key metrics help identify bottlenecks like a small key buffer size if the key read cache miss rate is high.

zendcon09mysqlfloridalinuxshow
Customize latency tracing
# sqlhist -e -n wakeup_lat -T -m lat 'SELECT end.next_comm AS comm, ’ 
‘(end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS lat ’ 
‘FROM sched_waking AS start JOIN sched_switch AS end ’ 
‘ON start.pid = end.next_pid’ 
‘WHERE end.next_prio < 100 && end.next_comm == "cyclictest"'
# trace-cmd start -e all -e wakeup_lat -R stacktrace
# cyclictest -l 1000 -p80 -i250 -a -t -q -m -d 0 -b 1000 --tracemark
# trace-cmd show -s | tail -16
<idle>-0 [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1
<idle>-0 [002] d..2 23454.902254: sched_switch: prev_comm=swapper/2 prev_pid=0 prev_prio=120
prev_state=R ==> next_comm=cyclictest next_pid=12275 next_prio=19
<idle>-0 [002] d..4 23454.902256: wakeup_lat: next_comm=cyclictest lat=17
<idle>-0 [002] d..5 23454.902258: <stack trace>
=> trace_event_raw_event_synth
=> action_trace
=> event_hist_trigger
=> event_triggers_call
=> trace_event_buffer_commit
=> trace_event_raw_event_sched_switch
=> __traceiter_sched_switch
=> __schedule
=> schedule_idle
=> do_idle
=> cpu_startup_entry
=> secondary_startup_64_no_verify
Customize latency tracing
# sqlhist -e -n wakeup_lat -T -m lat 'SELECT end.next_comm AS comm, ’ 
‘(end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS lat ’ 
‘FROM sched_waking AS start JOIN sched_switch AS end ’ 
‘ON start.pid = end.next_pid’ 
‘WHERE end.next_prio < 100 && end.next_comm == "cyclictest"'
# trace-cmd start -e all -e wakeup_lat -R stacktrace
# cyclictest -l 1000 -p80 -i250 -a -t -q -m -d 0 -b 1000 --tracemark
# trace-cmd show -s | tail -16
<idle>-0 [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1
<idle>-0 [002] d..2 23454.902254: sched_switch: prev_comm=swapper/2 prev_pid=0 prev_prio=120
prev_state=R ==> next_comm=cyclictest next_pid=12275 next_prio=19
<idle>-0 [002] d..4 23454.902256: wakeup_lat: next_comm=cyclictest lat=17
<idle>-0 [002] d..5 23454.902258: <stack trace>
=> trace_event_raw_event_synth
=> action_trace
=> event_hist_trigger
=> event_triggers_call
=> trace_event_buffer_commit
=> trace_event_raw_event_sched_switch
=> __traceiter_sched_switch
=> __schedule
=> schedule_idle
=> do_idle
=> cpu_startup_entry
=> secondary_startup_64_no_verify
Customize latency tracing
# sqlhist -e -n wakeup_lat -T -m lat 'SELECT end.next_comm AS comm, ’ 
‘(end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS lat ’ 
‘FROM sched_waking AS start JOIN sched_switch AS end ’ 
‘ON start.pid = end.next_pid’ 
‘WHERE end.next_prio < 100 && end.next_comm == "cyclictest"'
# trace-cmd start -e all -e wakeup_lat -R stacktrace
# cyclictest -l 1000 -p80 -i250 -a -t -q -m -d 0 -b 1000 --tracemark
# trace-cmd show -s | tail -16
<idle>-0 [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1
<idle>-0 [002] d..2 23454.902254: sched_switch: prev_comm=swapper/2 prev_pid=0 prev_prio=120
prev_state=R ==> next_comm=cyclictest next_pid=12275 next_prio=19
<idle>-0 [002] d..4 23454.902256: wakeup_lat: next_comm=cyclictest lat=17
<idle>-0 [002] d..5 23454.902258: <stack trace>
=> trace_event_raw_event_synth
=> action_trace
=> event_hist_trigger
=> event_triggers_call
=> trace_event_buffer_commit
=> trace_event_raw_event_sched_switch
=> __traceiter_sched_switch
=> __schedule
=> schedule_idle
=> do_idle
=> cpu_startup_entry
=> secondary_startup_64_no_verify
Customize latency tracing
# sqlhist -e -n wakeup_lat -T -m lat 'SELECT end.next_comm AS comm, ’ 
‘(end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS lat ’ 
‘FROM sched_waking AS start JOIN sched_switch AS end ’ 
‘ON start.pid = end.next_pid’ 
‘WHERE end.next_prio < 100 && end.next_comm == "cyclictest"'
# trace-cmd start -e all -e wakeup_lat -R stacktrace
# cyclictest -l 1000 -p80 -i250 -a -t -q -m -d 0 -b 1000 --tracemark
# trace-cmd show -s | tail -16
<idle>-0 [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1
<idle>-0 [002] d..2 23454.902254: sched_switch: prev_comm=swapper/2 prev_pid=0 prev_prio=120
prev_state=R ==> next_comm=cyclictest next_pid=12275 next_prio=19
<idle>-0 [002] d..4 23454.902256: wakeup_lat: next_comm=cyclictest lat=17
<idle>-0 [002] d..5 23454.902258: <stack trace>
=> trace_event_raw_event_synth
=> action_trace
=> event_hist_trigger
=> event_triggers_call
=> trace_event_buffer_commit
=> trace_event_raw_event_sched_switch
=> __traceiter_sched_switch
=> __schedule
=> schedule_idle
=> do_idle
=> cpu_startup_entry
=> secondary_startup_64_no_verify

Recommended for you

Mysql tracing
Mysql tracingMysql tracing
Mysql tracing

This document discusses various tools and techniques for profiling and optimizing MySQL query performance, including: - Using tools like Apache ab, JMeter, and Siege to measure baseline performance and identify focus areas like latency and throughput. - Profiling PHP applications with Xdebug to identify expensive queries and operations. - Analyzing slow query logs, MySQL query profiling and the performance schema to find slow and expensive queries. - Using EXPLAIN to analyze and optimize query execution plans and indexes. - MySQL Enterprise Monitor and Query Analyzer for centralized monitoring of queries across servers.

php barcelona 2010johannes schlter
Mysql tracing
Mysql tracingMysql tracing
Mysql tracing

This document discusses various tools and techniques for profiling and optimizing MySQL query performance, including: - Using tools like Apache ab, JMeter, and Siege to measure baseline performance and identify focus areas like latency and throughput. - Profiling PHP applications with Xdebug to identify expensive queries and operations. - Analyzing slow query logs, MySQL query profiling and the performance schema to find slow and expensive queries. - Using EXPLAIN to analyze and optimize query execution plans and indexes. - MySQL Enterprise Monitor and Query Analyzer for centralized monitoring of queries across servers.

php barcelona 2010johannes schlter
Undelete (and more) rows from the binary log
Undelete (and more) rows from the binary logUndelete (and more) rows from the binary log
Undelete (and more) rows from the binary log

The document describes how to undelete rows from MySQL binary logs without doing a full point-in-time recovery. It shows deleting a row from a table, finding the delete event in the binary log, decoding the event, rebuilding it as a write event, and replaying it to undo the delete. This allows quickly undeleting rows by manipulating the binary log directly rather than doing a slow full restore.

point-in-timeundeleterecovery
Customize latency tracing
# sqlhist -e -n wakeup_lat -T -m lat 'SELECT end.next_comm AS comm, ’ 
‘(end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS lat ’ 
‘FROM sched_waking AS start JOIN sched_switch AS end ’ 
‘ON start.pid = end.next_pid’ 
‘WHERE end.next_prio < 100 && end.next_comm == "cyclictest"'
# trace-cmd start -e all -e wakeup_lat -R stacktrace
# cyclictest -l 1000 -p80 -i250 -a -t -q -m -d 0 -b 1000 --tracemark
# trace-cmd show -s | tail -16
<idle>-0 [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1
<idle>-0 [002] d..2 23454.902254: sched_switch: prev_comm=swapper/2 prev_pid=0 prev_prio=120
prev_state=R ==> next_comm=cyclictest next_pid=12275 next_prio=19
<idle>-0 [002] d..4 23454.902256: wakeup_lat: next_comm=cyclictest lat=17
<idle>-0 [002] d..5 23454.902258: <stack trace>
=> trace_event_raw_event_synth
=> action_trace
=> event_hist_trigger
=> event_triggers_call
=> trace_event_buffer_commit
=> trace_event_raw_event_sched_switch
=> __traceiter_sched_switch
=> __schedule
=> schedule_idle
=> do_idle
=> cpu_startup_entry
=> secondary_startup_64_no_verify
Customize latency tracing
# trace-cmd extract -s
# trace-cmd report --cpu 2 | tail -30
<idle>-0 [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1
<idle>-0 [002] 23454.902239: sched_wakeup: cyclictest:12275 [19] CPU:002
<idle>-0 [002] 23454.902241: hrtimer_expire_exit: hrtimer=0xffffbbd68286fe60
<idle>-0 [002] 23454.902241: hrtimer_cancel: hrtimer=0xffffbbd6826efe70
<idle>-0 [002] 23454.902242: hrtimer_expire_entry: hrtimer=0xffffbbd6826efe70
<idle>-0 [002] 23454.902243: sched_waking: comm=cyclictest pid=12272
prio=120 target_cpu=002
<idle>-0 [002] 23454.902244: prandom_u32: ret=1102749734
<idle>-0 [002] 23454.902246: sched_wakeup: cyclictest:12272 [120] CPU:002
<idle>-0 [002] 23454.902247: hrtimer_expire_exit: hrtimer=0xffffbbd6826efe70
<idle>-0 [002] 23454.902248: write_msr: 6e0, value 4866ce957272
<idle>-0 [002] 23454.902249: local_timer_exit: vector=236
<idle>-0 [002] 23454.902250: cpu_idle: state=4294967295 cpu_id=2
<idle>-0 [002] 23454.902251: rcu_utilization: Start context switch
<idle>-0 [002] 23454.902252: rcu_utilization: End context switch
<idle>-0 [002] 23454.902253: prandom_u32: ret=3692516021
<idle>-0 [002] 23454.902254: sched_switch: swapper/2:0 [120] R ==>
cyclictest:12275 [19]
<idle>-0 [002] 23454.902256: wakeup_lat: next_comm=cyclictest lat=17
<idle>-0 [002] 23454.902258: kernel_stack: <stack trace >
=> trace_event_raw_event_synth (ffffffff8121a0db)
=> action_trace (ffffffff8121e9fb)
=> event_hist_trigger (ffffffff8121ca8d)
=> event_triggers_call (ffffffff81216c72)
[..]
Customize latency tracing
# trace-cmd extract -s
# trace-cmd report --cpu 2 | tail -30
<idle>-0 [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1
<idle>-0 [002] 23454.902239: sched_wakeup: cyclictest:12275 [19] CPU:002
<idle>-0 [002] 23454.902241: hrtimer_expire_exit: hrtimer=0xffffbbd68286fe60
<idle>-0 [002] 23454.902241: hrtimer_cancel: hrtimer=0xffffbbd6826efe70
<idle>-0 [002] 23454.902242: hrtimer_expire_entry: hrtimer=0xffffbbd6826efe70
<idle>-0 [002] 23454.902243: sched_waking: comm=cyclictest pid=12272
prio=120 target_cpu=002
<idle>-0 [002] 23454.902244: prandom_u32: ret=1102749734
<idle>-0 [002] 23454.902246: sched_wakeup: cyclictest:12272 [120] CPU:002
<idle>-0 [002] 23454.902247: hrtimer_expire_exit: hrtimer=0xffffbbd6826efe70
<idle>-0 [002] 23454.902248: write_msr: 6e0, value 4866ce957272
<idle>-0 [002] 23454.902249: local_timer_exit: vector=236
<idle>-0 [002] 23454.902250: cpu_idle: state=4294967295 cpu_id=2
<idle>-0 [002] 23454.902251: rcu_utilization: Start context switch
<idle>-0 [002] 23454.902252: rcu_utilization: End context switch
<idle>-0 [002] 23454.902253: prandom_u32: ret=3692516021
<idle>-0 [002] 23454.902254: sched_switch: swapper/2:0 [120] R ==>
cyclictest:12275 [19]
<idle>-0 [002] 23454.902256: wakeup_lat: next_comm=cyclictest lat=17
<idle>-0 [002] 23454.902258: kernel_stack: <stack trace >
=> trace_event_raw_event_synth (ffffffff8121a0db)
=> action_trace (ffffffff8121e9fb)
=> event_hist_trigger (ffffffff8121ca8d)
=> event_triggers_call (ffffffff81216c72)
[..]
Customize latency tracing
# trace-cmd extract -s
# trace-cmd report --cpu 2 | tail -30
<idle>-0 [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1
<idle>-0 [002] 23454.902239: sched_wakeup: cyclictest:12275 [19] CPU:002
<idle>-0 [002] 23454.902241: hrtimer_expire_exit: hrtimer=0xffffbbd68286fe60
<idle>-0 [002] 23454.902241: hrtimer_cancel: hrtimer=0xffffbbd6826efe70
<idle>-0 [002] 23454.902242: hrtimer_expire_entry: hrtimer=0xffffbbd6826efe70
<idle>-0 [002] 23454.902243: sched_waking: comm=cyclictest pid=12272
prio=120 target_cpu=002
<idle>-0 [002] 23454.902244: prandom_u32: ret=1102749734
<idle>-0 [002] 23454.902246: sched_wakeup: cyclictest:12272 [120] CPU:002
<idle>-0 [002] 23454.902247: hrtimer_expire_exit: hrtimer=0xffffbbd6826efe70
<idle>-0 [002] 23454.902248: write_msr: 6e0, value 4866ce957272
<idle>-0 [002] 23454.902249: local_timer_exit: vector=236
<idle>-0 [002] 23454.902250: cpu_idle: state=4294967295 cpu_id=2
<idle>-0 [002] 23454.902251: rcu_utilization: Start context switch
<idle>-0 [002] 23454.902252: rcu_utilization: End context switch
<idle>-0 [002] 23454.902253: prandom_u32: ret=3692516021
<idle>-0 [002] 23454.902254: sched_switch: swapper/2:0 [120] R ==>
cyclictest:12275 [19]
<idle>-0 [002] 23454.902256: wakeup_lat: next_comm=cyclictest lat=17
<idle>-0 [002] 23454.902258: kernel_stack: <stack trace >
=> trace_event_raw_event_synth (ffffffff8121a0db)
=> action_trace (ffffffff8121e9fb)
=> event_hist_trigger (ffffffff8121ca8d)
=> event_triggers_call (ffffffff81216c72)
[..]

Recommended for you

CONFidence 2015: DTrace + OSX = Fun - Andrzej Dyjak
CONFidence 2015: DTrace + OSX = Fun - Andrzej Dyjak   CONFidence 2015: DTrace + OSX = Fun - Andrzej Dyjak
CONFidence 2015: DTrace + OSX = Fun - Andrzej Dyjak

This document summarizes a presentation about using DTrace on OS X. It introduces DTrace as a dynamic tracing tool for user and kernel space. It discusses the D programming language used for writing DTrace scripts, including data types, variables, operators, and actions. Example one-liners and scripts are provided to demonstrate syscall tracking, memory allocation snooping, and hit tracing. The presentation outlines some past security work using DTrace and similar dynamic tracing tools. It concludes with proposing future work like more kernel and USDT tracing as well as Python bindings for DTrace.

confidencedtraceosx
Unconventional Methods to Identify Bottlenecks in Low-Latency and High-Throug...
Unconventional Methods to Identify Bottlenecks in Low-Latency and High-Throug...Unconventional Methods to Identify Bottlenecks in Low-Latency and High-Throug...
Unconventional Methods to Identify Bottlenecks in Low-Latency and High-Throug...

In this presentation, we explore how standard profiling and monitoring methods may fall short in identifying bottlenecks in low-latency data ingestion workflows. Instead, we showcase the power of simple yet clever methods that can uncover hidden performance limitations. Attendees will discover unconventional techniques, including clever logging, targeted instrumentation, and specialized metrics, to pinpoint bottlenecks accurately. Real-world use cases will be presented to demonstrate the effectiveness of these methods. By the end of the session, attendees will be equipped with alternative approaches to identify bottlenecks and optimize their low-latency data ingestion workflows for high throughput.

Mitigating the Impact of State Management in Cloud Stream Processing Systems
Mitigating the Impact of State Management in Cloud Stream Processing SystemsMitigating the Impact of State Management in Cloud Stream Processing Systems
Mitigating the Impact of State Management in Cloud Stream Processing Systems

Stream processing is a crucial component of modern data infrastructure, but constructing an efficient and scalable stream processing system can be challenging. Decoupling compute and storage architecture has emerged as an effective solution to these challenges, but it can introduce high latency issues, especially when dealing with complex continuous queries that necessitate managing extra-large internal states. In this talk, we focus on addressing the high latency issues associated with S3 storage in stream processing systems that employ a decoupled compute and storage architecture. We delve into the root causes of latency in this context and explore various techniques to minimize the impact of S3 latency on stream processing performance. Our proposed approach is to implement a tiered storage mechanism that leverages a blend of high-performance and low-cost storage tiers to reduce data movement between the compute and storage layers while maintaining efficient processing. Throughout the talk, we will present experimental results that demonstrate the effectiveness of our approach in mitigating the impact of S3 latency on stream processing. By the end of the talk, attendees will have gained insights into how to optimize their stream processing systems for reduced latency and improved cost-efficiency.

Customize latency tracing
# trace-cmd extract -s
# trace-cmd report --cpu 2 | tail -30
<idle>-0 [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1
<idle>-0 [002] 23454.902239: sched_wakeup: cyclictest:12275 [19] CPU:002
<idle>-0 [002] 23454.902241: hrtimer_expire_exit: hrtimer=0xffffbbd68286fe60
<idle>-0 [002] 23454.902241: hrtimer_cancel: hrtimer=0xffffbbd6826efe70
<idle>-0 [002] 23454.902242: hrtimer_expire_entry: hrtimer=0xffffbbd6826efe70
<idle>-0 [002] 23454.902243: sched_waking: comm=cyclictest pid=12272
prio=120 target_cpu=002
<idle>-0 [002] 23454.902244: prandom_u32: ret=1102749734
<idle>-0 [002] 23454.902246: sched_wakeup: cyclictest:12272 [120] CPU:002
<idle>-0 [002] 23454.902247: hrtimer_expire_exit: hrtimer=0xffffbbd6826efe70
<idle>-0 [002] 23454.902248: write_msr: 6e0, value 4866ce957272
<idle>-0 [002] 23454.902249: local_timer_exit: vector=236
<idle>-0 [002] 23454.902250: cpu_idle: state=4294967295 cpu_id=2
<idle>-0 [002] 23454.902251: rcu_utilization: Start context switch
<idle>-0 [002] 23454.902252: rcu_utilization: End context switch
<idle>-0 [002] 23454.902253: prandom_u32: ret=3692516021
<idle>-0 [002] 23454.902254: sched_switch: swapper/2:0 [120] R ==>
cyclictest:12275 [19]
<idle>-0 [002] 23454.902256: wakeup_lat: next_comm=cyclictest lat=17
<idle>-0 [002] 23454.902258: kernel_stack: <stack trace >
=> trace_event_raw_event_synth (ffffffff8121a0db)
=> action_trace (ffffffff8121e9fb)
=> event_hist_trigger (ffffffff8121ca8d)
=> event_triggers_call (ffffffff81216c72)
[..]
Customize latency tracing
# trace-cmd extract -s
# trace-cmd report --cpu 2 | tail -30
<idle>-0 [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1
<idle>-0 [002] 23454.902239: sched_wakeup: cyclictest:12275 [19] CPU:002
<idle>-0 [002] 23454.902241: hrtimer_expire_exit: hrtimer=0xffffbbd68286fe60
<idle>-0 [002] 23454.902241: hrtimer_cancel: hrtimer=0xffffbbd6826efe70
<idle>-0 [002] 23454.902242: hrtimer_expire_entry: hrtimer=0xffffbbd6826efe70
<idle>-0 [002] 23454.902243: sched_waking: comm=cyclictest pid=12272
prio=120 target_cpu=002
<idle>-0 [002] 23454.902244: prandom_u32: ret=1102749734
<idle>-0 [002] 23454.902246: sched_wakeup: cyclictest:12272 [120] CPU:002
<idle>-0 [002] 23454.902247: hrtimer_expire_exit: hrtimer=0xffffbbd6826efe70
<idle>-0 [002] 23454.902248: write_msr: 6e0, value 4866ce957272
<idle>-0 [002] 23454.902249: local_timer_exit: vector=236
<idle>-0 [002] 23454.902250: cpu_idle: state=4294967295 cpu_id=2
<idle>-0 [002] 23454.902251: rcu_utilization: Start context switch
<idle>-0 [002] 23454.902252: rcu_utilization: End context switch
<idle>-0 [002] 23454.902253: prandom_u32: ret=3692516021
<idle>-0 [002] 23454.902254: sched_switch: swapper/2:0 [120] R ==>
cyclictest:12275 [19]
<idle>-0 [002] 23454.902256: wakeup_lat: next_comm=cyclictest lat=17
<idle>-0 [002] 23454.902258: kernel_stack: <stack trace >
=> trace_event_raw_event_synth (ffffffff8121a0db)
=> action_trace (ffffffff8121e9fb)
=> event_hist_trigger (ffffffff8121ca8d)
=> event_triggers_call (ffffffff81216c72)
[..]
Customize latency tracing
# trace-cmd extract -s
# trace-cmd report --cpu 2 | tail -30
<idle>-0 [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1
<idle>-0 [002] 23454.902239: sched_wakeup: cyclictest:12275 [19] CPU:002
<idle>-0 [002] 23454.902241: hrtimer_expire_exit: hrtimer=0xffffbbd68286fe60
<idle>-0 [002] 23454.902241: hrtimer_cancel: hrtimer=0xffffbbd6826efe70
<idle>-0 [002] 23454.902242: hrtimer_expire_entry: hrtimer=0xffffbbd6826efe70
<idle>-0 [002] 23454.902243: sched_waking: comm=cyclictest pid=12272
prio=120 target_cpu=002
<idle>-0 [002] 23454.902244: prandom_u32: ret=1102749734
<idle>-0 [002] 23454.902246: sched_wakeup: cyclictest:12272 [120] CPU:002
<idle>-0 [002] 23454.902247: hrtimer_expire_exit: hrtimer=0xffffbbd6826efe70
<idle>-0 [002] 23454.902248: write_msr: 6e0, value 4866ce957272
<idle>-0 [002] 23454.902249: local_timer_exit: vector=236
<idle>-0 [002] 23454.902250: cpu_idle: state=4294967295 cpu_id=2
<idle>-0 [002] 23454.902251: rcu_utilization: Start context switch
<idle>-0 [002] 23454.902252: rcu_utilization: End context switch
<idle>-0 [002] 23454.902253: prandom_u32: ret=3692516021
<idle>-0 [002] 23454.902254: sched_switch: swapper/2:0 [120] R ==>
cyclictest:12275 [19]
<idle>-0 [002] 23454.902256: wakeup_lat: next_comm=cyclictest lat=17
<idle>-0 [002] 23454.902258: kernel_stack: <stack trace >
=> trace_event_raw_event_synth (ffffffff8121a0db)
=> action_trace (ffffffff8121e9fb)
=> event_hist_trigger (ffffffff8121ca8d)
=> event_triggers_call (ffffffff81216c72)
[..]
Customize latency tracing
# trace-cmd extract -s
# trace-cmd report --cpu 2 | tail -30
<idle>-0 [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1
<idle>-0 [002] 23454.902239: sched_wakeup: cyclictest:12275 [19] CPU:002
<idle>-0 [002] 23454.902241: hrtimer_expire_exit: hrtimer=0xffffbbd68286fe60
<idle>-0 [002] 23454.902241: hrtimer_cancel: hrtimer=0xffffbbd6826efe70
<idle>-0 [002] 23454.902242: hrtimer_expire_entry: hrtimer=0xffffbbd6826efe70
<idle>-0 [002] 23454.902243: sched_waking: comm=cyclictest pid=12272
prio=120 target_cpu=002
<idle>-0 [002] 23454.902244: prandom_u32: ret=1102749734
<idle>-0 [002] 23454.902246: sched_wakeup: cyclictest:12272 [120] CPU:002
<idle>-0 [002] 23454.902247: hrtimer_expire_exit: hrtimer=0xffffbbd6826efe70
<idle>-0 [002] 23454.902248: write_msr: 6e0, value 4866ce957272
<idle>-0 [002] 23454.902249: local_timer_exit: vector=236
<idle>-0 [002] 23454.902250: cpu_idle: state=4294967295 cpu_id=2
<idle>-0 [002] 23454.902251: rcu_utilization: Start context switch
<idle>-0 [002] 23454.902252: rcu_utilization: End context switch
<idle>-0 [002] 23454.902253: prandom_u32: ret=3692516021
<idle>-0 [002] 23454.902254: sched_switch: swapper/2:0 [120] R ==>
cyclictest:12275 [19]
<idle>-0 [002] 23454.902256: wakeup_lat: next_comm=cyclictest lat=17
<idle>-0 [002] 23454.902258: kernel_stack: <stack trace >
=> trace_event_raw_event_synth (ffffffff8121a0db)
=> action_trace (ffffffff8121e9fb)
=> event_hist_trigger (ffffffff8121ca8d)
=> event_triggers_call (ffffffff81216c72)
[..]

Recommended for you

Measuring the Impact of Network Latency at Twitter
Measuring the Impact of Network Latency at TwitterMeasuring the Impact of Network Latency at Twitter
Measuring the Impact of Network Latency at Twitter

Widya Salim and Victor Ma will outline the causal impact analysis, framework, and key learnings used to quantify the impact of reducing Twitter's network latency.

Architecting a High-Performance (Open Source) Distributed Message Queuing Sys...
Architecting a High-Performance (Open Source) Distributed Message Queuing Sys...Architecting a High-Performance (Open Source) Distributed Message Queuing Sys...
Architecting a High-Performance (Open Source) Distributed Message Queuing Sys...

BlazingMQ is a new open source* distributed message queuing system developed at and published by Bloomberg. It provides highly-performant queues to applications for asynchronous, efficient, and reliable communication. This system has been used at scale at Bloomberg for eight years, where it moves terabytes of data and billions of messages across tens of thousands of queues in production every day. BlazingMQ provides highly-available, fault-tolerant queues courtesy of replication based on the Raft consensus algorithm. In addition, it provides a rich set of enterprise message routing strategies, enabling users to implement a variety of scenarios for message processing. Written in C++ from the ground up, BlazingMQ has been architected with low latency as one of its core requirements. This has resulted in some unique design and implementation choices at all levels of the system, such as its lock-free threading model, custom memory allocators, compact wire protocol, multi-hop network topology, and more. This talk will provide an overview of BlazingMQ. We will then delve into the system’s core design principles, architecture, and implementation details in order to explore the crucial role they play in its performance and reliability. *BlazingMQ will be released as open source between now and P99 (exact timing is still TBD)

Noise Canceling RUM by Tim Vereecke, Akamai
Noise Canceling RUM by Tim Vereecke, AkamaiNoise Canceling RUM by Tim Vereecke, Akamai
Noise Canceling RUM by Tim Vereecke, Akamai

Noisy Real User Monitoring (RUM) data can ruin your P99! We introduce a fresh concept called ""Human Visible Navigations"" (HVN) to tackle this risk; we focus on the experiences you actually care about when talking about the speed of our sites: - Human: We exclude noise coming from bots and synthetic measurements. - Visible: We remove any partial or fully hidden experiences. These tend to be very slow but users don’t see this slowness. - Navigations: We ignore lightning fast back-forward navigations which usually have few optimisation opportunities. Adopting Human Visible Navigations provides you with these key benefits: - Fewer changes staying below the radar - Fewer data fluctuations - Fewer blindspots when finding bottlenecks - Better correlation with business metrics This is supported by plenty of real world examples coming from the world's largest scale modeling site (6M Monthly visits) in combination with aggregated data from the brand new rumarchive.com (open source) After attending this session; your P99 and other percentiles will become less noisy and easier to tune!

Brought to you by
Steven Rostedt
rostedt@goodmis.org
@srostedt

More Related Content

What's hot

Percona Toolkit for Effective MySQL Administration
Percona Toolkit for Effective MySQL AdministrationPercona Toolkit for Effective MySQL Administration
Percona Toolkit for Effective MySQL Administration
Mydbops
 
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
Hironobu Suzuki
 
Reverse Mapping (rmap) in Linux Kernel
Reverse Mapping (rmap) in Linux KernelReverse Mapping (rmap) in Linux Kernel
Reverse Mapping (rmap) in Linux Kernel
Adrian Huang
 
Deep dive into PostgreSQL statistics.
Deep dive into PostgreSQL statistics.Deep dive into PostgreSQL statistics.
Deep dive into PostgreSQL statistics.
Alexey Lesovsky
 
Linuxのプロセススケジューラ(Reading the Linux process scheduler)
Linuxのプロセススケジューラ(Reading the Linux process scheduler)Linuxのプロセススケジューラ(Reading the Linux process scheduler)
Linuxのプロセススケジューラ(Reading the Linux process scheduler)
Hiraku Toyooka
 
Evolution of MongoDB Replicaset and Its Best Practices
Evolution of MongoDB Replicaset and Its Best PracticesEvolution of MongoDB Replicaset and Its Best Practices
Evolution of MongoDB Replicaset and Its Best Practices
Mydbops
 
MaxScale이해와활용-2023.11
MaxScale이해와활용-2023.11MaxScale이해와활용-2023.11
MaxScale이해와활용-2023.11
NeoClova
 
MySQL Parallel Replication by Booking.com
MySQL Parallel Replication by Booking.comMySQL Parallel Replication by Booking.com
MySQL Parallel Replication by Booking.com
Jean-François Gagné
 
Galera cluster for high availability
Galera cluster for high availability Galera cluster for high availability
Galera cluster for high availability
Mydbops
 
qemu + gdb + sample_code: Run sample code in QEMU OS and observe Linux Kernel...
qemu + gdb + sample_code: Run sample code in QEMU OS and observe Linux Kernel...qemu + gdb + sample_code: Run sample code in QEMU OS and observe Linux Kernel...
qemu + gdb + sample_code: Run sample code in QEMU OS and observe Linux Kernel...
Adrian Huang
 
Delivering Docker & K3s worloads to IoT Edge devices
Delivering Docker & K3s worloads to IoT Edge devicesDelivering Docker & K3s worloads to IoT Edge devices
Delivering Docker & K3s worloads to IoT Edge devices
Ajeet Singh Raina
 
How does PostgreSQL work with disks: a DBA's checklist in detail. PGConf.US 2015
How does PostgreSQL work with disks: a DBA's checklist in detail. PGConf.US 2015How does PostgreSQL work with disks: a DBA's checklist in detail. PGConf.US 2015
How does PostgreSQL work with disks: a DBA's checklist in detail. PGConf.US 2015
PostgreSQL-Consulting
 
Java Performance Analysis on Linux with Flame Graphs
Java Performance Analysis on Linux with Flame GraphsJava Performance Analysis on Linux with Flame Graphs
Java Performance Analysis on Linux with Flame Graphs
Brendan Gregg
 
Kernel Recipes 2017 - Understanding the Linux kernel via ftrace - Steven Rostedt
Kernel Recipes 2017 - Understanding the Linux kernel via ftrace - Steven RostedtKernel Recipes 2017 - Understanding the Linux kernel via ftrace - Steven Rostedt
Kernel Recipes 2017 - Understanding the Linux kernel via ftrace - Steven Rostedt
Anne Nicolas
 
Linux 4.x Tracing Tools: Using BPF Superpowers
Linux 4.x Tracing Tools: Using BPF SuperpowersLinux 4.x Tracing Tools: Using BPF Superpowers
Linux 4.x Tracing Tools: Using BPF Superpowers
Brendan Gregg
 
Patroni - HA PostgreSQL made easy
Patroni - HA PostgreSQL made easyPatroni - HA PostgreSQL made easy
Patroni - HA PostgreSQL made easy
Alexander Kukushkin
 
PostgreSQL Streaming Replication Cheatsheet
PostgreSQL Streaming Replication CheatsheetPostgreSQL Streaming Replication Cheatsheet
PostgreSQL Streaming Replication Cheatsheet
Alexey Lesovsky
 
Using Optimizer Hints to Improve MySQL Query Performance
Using Optimizer Hints to Improve MySQL Query PerformanceUsing Optimizer Hints to Improve MySQL Query Performance
Using Optimizer Hints to Improve MySQL Query Performance
oysteing
 
Linux 4.x Tracing: Performance Analysis with bcc/BPF
Linux 4.x Tracing: Performance Analysis with bcc/BPFLinux 4.x Tracing: Performance Analysis with bcc/BPF
Linux 4.x Tracing: Performance Analysis with bcc/BPF
Brendan Gregg
 
Process Scheduler and Balancer in Linux Kernel
Process Scheduler and Balancer in Linux KernelProcess Scheduler and Balancer in Linux Kernel
Process Scheduler and Balancer in Linux Kernel
Haifeng Li
 

What's hot (20)

Percona Toolkit for Effective MySQL Administration
Percona Toolkit for Effective MySQL AdministrationPercona Toolkit for Effective MySQL Administration
Percona Toolkit for Effective MySQL Administration
 
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
 
Reverse Mapping (rmap) in Linux Kernel
Reverse Mapping (rmap) in Linux KernelReverse Mapping (rmap) in Linux Kernel
Reverse Mapping (rmap) in Linux Kernel
 
Deep dive into PostgreSQL statistics.
Deep dive into PostgreSQL statistics.Deep dive into PostgreSQL statistics.
Deep dive into PostgreSQL statistics.
 
Linuxのプロセススケジューラ(Reading the Linux process scheduler)
Linuxのプロセススケジューラ(Reading the Linux process scheduler)Linuxのプロセススケジューラ(Reading the Linux process scheduler)
Linuxのプロセススケジューラ(Reading the Linux process scheduler)
 
Evolution of MongoDB Replicaset and Its Best Practices
Evolution of MongoDB Replicaset and Its Best PracticesEvolution of MongoDB Replicaset and Its Best Practices
Evolution of MongoDB Replicaset and Its Best Practices
 
MaxScale이해와활용-2023.11
MaxScale이해와활용-2023.11MaxScale이해와활용-2023.11
MaxScale이해와활용-2023.11
 
MySQL Parallel Replication by Booking.com
MySQL Parallel Replication by Booking.comMySQL Parallel Replication by Booking.com
MySQL Parallel Replication by Booking.com
 
Galera cluster for high availability
Galera cluster for high availability Galera cluster for high availability
Galera cluster for high availability
 
qemu + gdb + sample_code: Run sample code in QEMU OS and observe Linux Kernel...
qemu + gdb + sample_code: Run sample code in QEMU OS and observe Linux Kernel...qemu + gdb + sample_code: Run sample code in QEMU OS and observe Linux Kernel...
qemu + gdb + sample_code: Run sample code in QEMU OS and observe Linux Kernel...
 
Delivering Docker & K3s worloads to IoT Edge devices
Delivering Docker & K3s worloads to IoT Edge devicesDelivering Docker & K3s worloads to IoT Edge devices
Delivering Docker & K3s worloads to IoT Edge devices
 
How does PostgreSQL work with disks: a DBA's checklist in detail. PGConf.US 2015
How does PostgreSQL work with disks: a DBA's checklist in detail. PGConf.US 2015How does PostgreSQL work with disks: a DBA's checklist in detail. PGConf.US 2015
How does PostgreSQL work with disks: a DBA's checklist in detail. PGConf.US 2015
 
Java Performance Analysis on Linux with Flame Graphs
Java Performance Analysis on Linux with Flame GraphsJava Performance Analysis on Linux with Flame Graphs
Java Performance Analysis on Linux with Flame Graphs
 
Kernel Recipes 2017 - Understanding the Linux kernel via ftrace - Steven Rostedt
Kernel Recipes 2017 - Understanding the Linux kernel via ftrace - Steven RostedtKernel Recipes 2017 - Understanding the Linux kernel via ftrace - Steven Rostedt
Kernel Recipes 2017 - Understanding the Linux kernel via ftrace - Steven Rostedt
 
Linux 4.x Tracing Tools: Using BPF Superpowers
Linux 4.x Tracing Tools: Using BPF SuperpowersLinux 4.x Tracing Tools: Using BPF Superpowers
Linux 4.x Tracing Tools: Using BPF Superpowers
 
Patroni - HA PostgreSQL made easy
Patroni - HA PostgreSQL made easyPatroni - HA PostgreSQL made easy
Patroni - HA PostgreSQL made easy
 
PostgreSQL Streaming Replication Cheatsheet
PostgreSQL Streaming Replication CheatsheetPostgreSQL Streaming Replication Cheatsheet
PostgreSQL Streaming Replication Cheatsheet
 
Using Optimizer Hints to Improve MySQL Query Performance
Using Optimizer Hints to Improve MySQL Query PerformanceUsing Optimizer Hints to Improve MySQL Query Performance
Using Optimizer Hints to Improve MySQL Query Performance
 
Linux 4.x Tracing: Performance Analysis with bcc/BPF
Linux 4.x Tracing: Performance Analysis with bcc/BPFLinux 4.x Tracing: Performance Analysis with bcc/BPF
Linux 4.x Tracing: Performance Analysis with bcc/BPF
 
Process Scheduler and Balancer in Linux Kernel
Process Scheduler and Balancer in Linux KernelProcess Scheduler and Balancer in Linux Kernel
Process Scheduler and Balancer in Linux Kernel
 

Similar to New Ways to Find Latency in Linux Using Tracing

Performance Schema for MySQL Troubleshooting
Performance Schema for MySQL TroubleshootingPerformance Schema for MySQL Troubleshooting
Performance Schema for MySQL Troubleshooting
Sveta Smirnova
 
Percona Live UK 2014 Part III
Percona Live UK 2014  Part IIIPercona Live UK 2014  Part III
Percona Live UK 2014 Part III
Alkin Tezuysal
 
Kernel Recipes 2019 - ftrace: Where modifying a running kernel all started
Kernel Recipes 2019 - ftrace: Where modifying a running kernel all startedKernel Recipes 2019 - ftrace: Where modifying a running kernel all started
Kernel Recipes 2019 - ftrace: Where modifying a running kernel all started
Anne Nicolas
 
OSDC 2017 - Werner Fischer - Linux performance profiling and monitoring
OSDC 2017 - Werner Fischer - Linux performance profiling and monitoringOSDC 2017 - Werner Fischer - Linux performance profiling and monitoring
OSDC 2017 - Werner Fischer - Linux performance profiling and monitoring
NETWAYS
 
Interruption Timer Périodique
Interruption Timer PériodiqueInterruption Timer Périodique
Interruption Timer Périodique
Anne Nicolas
 
Kernel Recipes 2017: Performance Analysis with BPF
Kernel Recipes 2017: Performance Analysis with BPFKernel Recipes 2017: Performance Analysis with BPF
Kernel Recipes 2017: Performance Analysis with BPF
Brendan Gregg
 
Kernel Recipes 2017 - Performance analysis Superpowers with Linux BPF - Brend...
Kernel Recipes 2017 - Performance analysis Superpowers with Linux BPF - Brend...Kernel Recipes 2017 - Performance analysis Superpowers with Linux BPF - Brend...
Kernel Recipes 2017 - Performance analysis Superpowers with Linux BPF - Brend...
Anne Nicolas
 
pg_proctab: Accessing System Stats in PostgreSQL
pg_proctab: Accessing System Stats in PostgreSQLpg_proctab: Accessing System Stats in PostgreSQL
pg_proctab: Accessing System Stats in PostgreSQL
Mark Wong
 
pg_proctab: Accessing System Stats in PostgreSQL
pg_proctab: Accessing System Stats in PostgreSQLpg_proctab: Accessing System Stats in PostgreSQL
pg_proctab: Accessing System Stats in PostgreSQL
Command Prompt., Inc
 
OSSNA 2017 Performance Analysis Superpowers with Linux BPF
OSSNA 2017 Performance Analysis Superpowers with Linux BPFOSSNA 2017 Performance Analysis Superpowers with Linux BPF
OSSNA 2017 Performance Analysis Superpowers with Linux BPF
Brendan Gregg
 
EKON22 Introduction to Machinelearning
EKON22 Introduction to MachinelearningEKON22 Introduction to Machinelearning
EKON22 Introduction to Machinelearning
Max Kleiner
 
bcc/BPF tools - Strategy, current tools, future challenges
bcc/BPF tools - Strategy, current tools, future challengesbcc/BPF tools - Strategy, current tools, future challenges
bcc/BPF tools - Strategy, current tools, future challenges
IO Visor Project
 
BPF Tools 2017
BPF Tools 2017BPF Tools 2017
BPF Tools 2017
Brendan Gregg
 
Debugging linux issues with eBPF
Debugging linux issues with eBPFDebugging linux issues with eBPF
Debugging linux issues with eBPF
Ivan Babrou
 
ANALYZE for executable statements - a new way to do optimizer troubleshooting...
ANALYZE for executable statements - a new way to do optimizer troubleshooting...ANALYZE for executable statements - a new way to do optimizer troubleshooting...
ANALYZE for executable statements - a new way to do optimizer troubleshooting...
Sergey Petrunya
 
Perf Tuning Short
Perf Tuning ShortPerf Tuning Short
Perf Tuning Short
Ligaya Turmelle
 
Mysql tracing
Mysql tracingMysql tracing
Mysql tracing
Anis Berejeb
 
Mysql tracing
Mysql tracingMysql tracing
Mysql tracing
Anis Berejeb
 
Undelete (and more) rows from the binary log
Undelete (and more) rows from the binary logUndelete (and more) rows from the binary log
Undelete (and more) rows from the binary log
Frederic Descamps
 
CONFidence 2015: DTrace + OSX = Fun - Andrzej Dyjak
CONFidence 2015: DTrace + OSX = Fun - Andrzej Dyjak   CONFidence 2015: DTrace + OSX = Fun - Andrzej Dyjak
CONFidence 2015: DTrace + OSX = Fun - Andrzej Dyjak
PROIDEA
 

Similar to New Ways to Find Latency in Linux Using Tracing (20)

Performance Schema for MySQL Troubleshooting
Performance Schema for MySQL TroubleshootingPerformance Schema for MySQL Troubleshooting
Performance Schema for MySQL Troubleshooting
 
Percona Live UK 2014 Part III
Percona Live UK 2014  Part IIIPercona Live UK 2014  Part III
Percona Live UK 2014 Part III
 
Kernel Recipes 2019 - ftrace: Where modifying a running kernel all started
Kernel Recipes 2019 - ftrace: Where modifying a running kernel all startedKernel Recipes 2019 - ftrace: Where modifying a running kernel all started
Kernel Recipes 2019 - ftrace: Where modifying a running kernel all started
 
OSDC 2017 - Werner Fischer - Linux performance profiling and monitoring
OSDC 2017 - Werner Fischer - Linux performance profiling and monitoringOSDC 2017 - Werner Fischer - Linux performance profiling and monitoring
OSDC 2017 - Werner Fischer - Linux performance profiling and monitoring
 
Interruption Timer Périodique
Interruption Timer PériodiqueInterruption Timer Périodique
Interruption Timer Périodique
 
Kernel Recipes 2017: Performance Analysis with BPF
Kernel Recipes 2017: Performance Analysis with BPFKernel Recipes 2017: Performance Analysis with BPF
Kernel Recipes 2017: Performance Analysis with BPF
 
Kernel Recipes 2017 - Performance analysis Superpowers with Linux BPF - Brend...
Kernel Recipes 2017 - Performance analysis Superpowers with Linux BPF - Brend...Kernel Recipes 2017 - Performance analysis Superpowers with Linux BPF - Brend...
Kernel Recipes 2017 - Performance analysis Superpowers with Linux BPF - Brend...
 
pg_proctab: Accessing System Stats in PostgreSQL
pg_proctab: Accessing System Stats in PostgreSQLpg_proctab: Accessing System Stats in PostgreSQL
pg_proctab: Accessing System Stats in PostgreSQL
 
pg_proctab: Accessing System Stats in PostgreSQL
pg_proctab: Accessing System Stats in PostgreSQLpg_proctab: Accessing System Stats in PostgreSQL
pg_proctab: Accessing System Stats in PostgreSQL
 
OSSNA 2017 Performance Analysis Superpowers with Linux BPF
OSSNA 2017 Performance Analysis Superpowers with Linux BPFOSSNA 2017 Performance Analysis Superpowers with Linux BPF
OSSNA 2017 Performance Analysis Superpowers with Linux BPF
 
EKON22 Introduction to Machinelearning
EKON22 Introduction to MachinelearningEKON22 Introduction to Machinelearning
EKON22 Introduction to Machinelearning
 
bcc/BPF tools - Strategy, current tools, future challenges
bcc/BPF tools - Strategy, current tools, future challengesbcc/BPF tools - Strategy, current tools, future challenges
bcc/BPF tools - Strategy, current tools, future challenges
 
BPF Tools 2017
BPF Tools 2017BPF Tools 2017
BPF Tools 2017
 
Debugging linux issues with eBPF
Debugging linux issues with eBPFDebugging linux issues with eBPF
Debugging linux issues with eBPF
 
ANALYZE for executable statements - a new way to do optimizer troubleshooting...
ANALYZE for executable statements - a new way to do optimizer troubleshooting...ANALYZE for executable statements - a new way to do optimizer troubleshooting...
ANALYZE for executable statements - a new way to do optimizer troubleshooting...
 
Perf Tuning Short
Perf Tuning ShortPerf Tuning Short
Perf Tuning Short
 
Mysql tracing
Mysql tracingMysql tracing
Mysql tracing
 
Mysql tracing
Mysql tracingMysql tracing
Mysql tracing
 
Undelete (and more) rows from the binary log
Undelete (and more) rows from the binary logUndelete (and more) rows from the binary log
Undelete (and more) rows from the binary log
 
CONFidence 2015: DTrace + OSX = Fun - Andrzej Dyjak
CONFidence 2015: DTrace + OSX = Fun - Andrzej Dyjak   CONFidence 2015: DTrace + OSX = Fun - Andrzej Dyjak
CONFidence 2015: DTrace + OSX = Fun - Andrzej Dyjak
 

More from ScyllaDB

Unconventional Methods to Identify Bottlenecks in Low-Latency and High-Throug...
Unconventional Methods to Identify Bottlenecks in Low-Latency and High-Throug...Unconventional Methods to Identify Bottlenecks in Low-Latency and High-Throug...
Unconventional Methods to Identify Bottlenecks in Low-Latency and High-Throug...
ScyllaDB
 
Mitigating the Impact of State Management in Cloud Stream Processing Systems
Mitigating the Impact of State Management in Cloud Stream Processing SystemsMitigating the Impact of State Management in Cloud Stream Processing Systems
Mitigating the Impact of State Management in Cloud Stream Processing Systems
ScyllaDB
 
Measuring the Impact of Network Latency at Twitter
Measuring the Impact of Network Latency at TwitterMeasuring the Impact of Network Latency at Twitter
Measuring the Impact of Network Latency at Twitter
ScyllaDB
 
Architecting a High-Performance (Open Source) Distributed Message Queuing Sys...
Architecting a High-Performance (Open Source) Distributed Message Queuing Sys...Architecting a High-Performance (Open Source) Distributed Message Queuing Sys...
Architecting a High-Performance (Open Source) Distributed Message Queuing Sys...
ScyllaDB
 
Noise Canceling RUM by Tim Vereecke, Akamai
Noise Canceling RUM by Tim Vereecke, AkamaiNoise Canceling RUM by Tim Vereecke, Akamai
Noise Canceling RUM by Tim Vereecke, Akamai
ScyllaDB
 
Running a Go App in Kubernetes: CPU Impacts
Running a Go App in Kubernetes: CPU ImpactsRunning a Go App in Kubernetes: CPU Impacts
Running a Go App in Kubernetes: CPU Impacts
ScyllaDB
 
Always-on Profiling of All Linux Threads, On-CPU and Off-CPU, with eBPF & Con...
Always-on Profiling of All Linux Threads, On-CPU and Off-CPU, with eBPF & Con...Always-on Profiling of All Linux Threads, On-CPU and Off-CPU, with eBPF & Con...
Always-on Profiling of All Linux Threads, On-CPU and Off-CPU, with eBPF & Con...
ScyllaDB
 
Performance Budgets for the Real World by Tammy Everts
Performance Budgets for the Real World by Tammy EvertsPerformance Budgets for the Real World by Tammy Everts
Performance Budgets for the Real World by Tammy Everts
ScyllaDB
 
Using Libtracecmd to Analyze Your Latency and Performance Troubles
Using Libtracecmd to Analyze Your Latency and Performance TroublesUsing Libtracecmd to Analyze Your Latency and Performance Troubles
Using Libtracecmd to Analyze Your Latency and Performance Troubles
ScyllaDB
 
Reducing P99 Latencies with Generational ZGC
Reducing P99 Latencies with Generational ZGCReducing P99 Latencies with Generational ZGC
Reducing P99 Latencies with Generational ZGC
ScyllaDB
 
5 Hours to 7.7 Seconds: How Database Tricks Sped up Rust Linting Over 2000X
5 Hours to 7.7 Seconds: How Database Tricks Sped up Rust Linting Over 2000X5 Hours to 7.7 Seconds: How Database Tricks Sped up Rust Linting Over 2000X
5 Hours to 7.7 Seconds: How Database Tricks Sped up Rust Linting Over 2000X
ScyllaDB
 
How Netflix Builds High Performance Applications at Global Scale
How Netflix Builds High Performance Applications at Global ScaleHow Netflix Builds High Performance Applications at Global Scale
How Netflix Builds High Performance Applications at Global Scale
ScyllaDB
 
Conquering Load Balancing: Experiences from ScyllaDB Drivers
Conquering Load Balancing: Experiences from ScyllaDB DriversConquering Load Balancing: Experiences from ScyllaDB Drivers
Conquering Load Balancing: Experiences from ScyllaDB Drivers
ScyllaDB
 
Interaction Latency: Square's User-Centric Mobile Performance Metric
Interaction Latency: Square's User-Centric Mobile Performance MetricInteraction Latency: Square's User-Centric Mobile Performance Metric
Interaction Latency: Square's User-Centric Mobile Performance Metric
ScyllaDB
 
How to Avoid Learning the Linux-Kernel Memory Model
How to Avoid Learning the Linux-Kernel Memory ModelHow to Avoid Learning the Linux-Kernel Memory Model
How to Avoid Learning the Linux-Kernel Memory Model
ScyllaDB
 
99.99% of Your Traces are Trash by Paige Cruz
99.99% of Your Traces are Trash by Paige Cruz99.99% of Your Traces are Trash by Paige Cruz
99.99% of Your Traces are Trash by Paige Cruz
ScyllaDB
 
Square's Lessons Learned from Implementing a Key-Value Store with Raft
Square's Lessons Learned from Implementing a Key-Value Store with RaftSquare's Lessons Learned from Implementing a Key-Value Store with Raft
Square's Lessons Learned from Implementing a Key-Value Store with Raft
ScyllaDB
 
Making Python 100x Faster with Less Than 100 Lines of Rust
Making Python 100x Faster with Less Than 100 Lines of RustMaking Python 100x Faster with Less Than 100 Lines of Rust
Making Python 100x Faster with Less Than 100 Lines of Rust
ScyllaDB
 
A Deep Dive Into Concurrent React by Matheus Albuquerque
A Deep Dive Into Concurrent React by Matheus AlbuquerqueA Deep Dive Into Concurrent React by Matheus Albuquerque
A Deep Dive Into Concurrent React by Matheus Albuquerque
ScyllaDB
 
The Latency Stack: Discovering Surprising Sources of Latency
The Latency Stack: Discovering Surprising Sources of LatencyThe Latency Stack: Discovering Surprising Sources of Latency
The Latency Stack: Discovering Surprising Sources of Latency
ScyllaDB
 

More from ScyllaDB (20)

Unconventional Methods to Identify Bottlenecks in Low-Latency and High-Throug...
Unconventional Methods to Identify Bottlenecks in Low-Latency and High-Throug...Unconventional Methods to Identify Bottlenecks in Low-Latency and High-Throug...
Unconventional Methods to Identify Bottlenecks in Low-Latency and High-Throug...
 
Mitigating the Impact of State Management in Cloud Stream Processing Systems
Mitigating the Impact of State Management in Cloud Stream Processing SystemsMitigating the Impact of State Management in Cloud Stream Processing Systems
Mitigating the Impact of State Management in Cloud Stream Processing Systems
 
Measuring the Impact of Network Latency at Twitter
Measuring the Impact of Network Latency at TwitterMeasuring the Impact of Network Latency at Twitter
Measuring the Impact of Network Latency at Twitter
 
Architecting a High-Performance (Open Source) Distributed Message Queuing Sys...
Architecting a High-Performance (Open Source) Distributed Message Queuing Sys...Architecting a High-Performance (Open Source) Distributed Message Queuing Sys...
Architecting a High-Performance (Open Source) Distributed Message Queuing Sys...
 
Noise Canceling RUM by Tim Vereecke, Akamai
Noise Canceling RUM by Tim Vereecke, AkamaiNoise Canceling RUM by Tim Vereecke, Akamai
Noise Canceling RUM by Tim Vereecke, Akamai
 
Running a Go App in Kubernetes: CPU Impacts
Running a Go App in Kubernetes: CPU ImpactsRunning a Go App in Kubernetes: CPU Impacts
Running a Go App in Kubernetes: CPU Impacts
 
Always-on Profiling of All Linux Threads, On-CPU and Off-CPU, with eBPF & Con...
Always-on Profiling of All Linux Threads, On-CPU and Off-CPU, with eBPF & Con...Always-on Profiling of All Linux Threads, On-CPU and Off-CPU, with eBPF & Con...
Always-on Profiling of All Linux Threads, On-CPU and Off-CPU, with eBPF & Con...
 
Performance Budgets for the Real World by Tammy Everts
Performance Budgets for the Real World by Tammy EvertsPerformance Budgets for the Real World by Tammy Everts
Performance Budgets for the Real World by Tammy Everts
 
Using Libtracecmd to Analyze Your Latency and Performance Troubles
Using Libtracecmd to Analyze Your Latency and Performance TroublesUsing Libtracecmd to Analyze Your Latency and Performance Troubles
Using Libtracecmd to Analyze Your Latency and Performance Troubles
 
Reducing P99 Latencies with Generational ZGC
Reducing P99 Latencies with Generational ZGCReducing P99 Latencies with Generational ZGC
Reducing P99 Latencies with Generational ZGC
 
5 Hours to 7.7 Seconds: How Database Tricks Sped up Rust Linting Over 2000X
5 Hours to 7.7 Seconds: How Database Tricks Sped up Rust Linting Over 2000X5 Hours to 7.7 Seconds: How Database Tricks Sped up Rust Linting Over 2000X
5 Hours to 7.7 Seconds: How Database Tricks Sped up Rust Linting Over 2000X
 
How Netflix Builds High Performance Applications at Global Scale
How Netflix Builds High Performance Applications at Global ScaleHow Netflix Builds High Performance Applications at Global Scale
How Netflix Builds High Performance Applications at Global Scale
 
Conquering Load Balancing: Experiences from ScyllaDB Drivers
Conquering Load Balancing: Experiences from ScyllaDB DriversConquering Load Balancing: Experiences from ScyllaDB Drivers
Conquering Load Balancing: Experiences from ScyllaDB Drivers
 
Interaction Latency: Square's User-Centric Mobile Performance Metric
Interaction Latency: Square's User-Centric Mobile Performance MetricInteraction Latency: Square's User-Centric Mobile Performance Metric
Interaction Latency: Square's User-Centric Mobile Performance Metric
 
How to Avoid Learning the Linux-Kernel Memory Model
How to Avoid Learning the Linux-Kernel Memory ModelHow to Avoid Learning the Linux-Kernel Memory Model
How to Avoid Learning the Linux-Kernel Memory Model
 
99.99% of Your Traces are Trash by Paige Cruz
99.99% of Your Traces are Trash by Paige Cruz99.99% of Your Traces are Trash by Paige Cruz
99.99% of Your Traces are Trash by Paige Cruz
 
Square's Lessons Learned from Implementing a Key-Value Store with Raft
Square's Lessons Learned from Implementing a Key-Value Store with RaftSquare's Lessons Learned from Implementing a Key-Value Store with Raft
Square's Lessons Learned from Implementing a Key-Value Store with Raft
 
Making Python 100x Faster with Less Than 100 Lines of Rust
Making Python 100x Faster with Less Than 100 Lines of RustMaking Python 100x Faster with Less Than 100 Lines of Rust
Making Python 100x Faster with Less Than 100 Lines of Rust
 
A Deep Dive Into Concurrent React by Matheus Albuquerque
A Deep Dive Into Concurrent React by Matheus AlbuquerqueA Deep Dive Into Concurrent React by Matheus Albuquerque
A Deep Dive Into Concurrent React by Matheus Albuquerque
 
The Latency Stack: Discovering Surprising Sources of Latency
The Latency Stack: Discovering Surprising Sources of LatencyThe Latency Stack: Discovering Surprising Sources of Latency
The Latency Stack: Discovering Surprising Sources of Latency
 

Recently uploaded

Cookies program to display the information though cookie creation
Cookies program to display the information though cookie creationCookies program to display the information though cookie creation
Cookies program to display the information though cookie creation
shanthidl1
 
How Social Media Hackers Help You to See Your Wife's Message.pdf
How Social Media Hackers Help You to See Your Wife's Message.pdfHow Social Media Hackers Help You to See Your Wife's Message.pdf
How Social Media Hackers Help You to See Your Wife's Message.pdf
HackersList
 
Observability For You and Me with OpenTelemetry
Observability For You and Me with OpenTelemetryObservability For You and Me with OpenTelemetry
Observability For You and Me with OpenTelemetry
Eric D. Schabell
 
Choose our Linux Web Hosting for a seamless and successful online presence
Choose our Linux Web Hosting for a seamless and successful online presenceChoose our Linux Web Hosting for a seamless and successful online presence
Choose our Linux Web Hosting for a seamless and successful online presence
rajancomputerfbd
 
TrustArc Webinar - 2024 Data Privacy Trends: A Mid-Year Check-In
TrustArc Webinar - 2024 Data Privacy Trends: A Mid-Year Check-InTrustArc Webinar - 2024 Data Privacy Trends: A Mid-Year Check-In
TrustArc Webinar - 2024 Data Privacy Trends: A Mid-Year Check-In
TrustArc
 
論文紹介:A Systematic Survey of Prompt Engineering on Vision-Language Foundation ...
論文紹介:A Systematic Survey of Prompt Engineering on Vision-Language Foundation ...論文紹介:A Systematic Survey of Prompt Engineering on Vision-Language Foundation ...
論文紹介:A Systematic Survey of Prompt Engineering on Vision-Language Foundation ...
Toru Tamaki
 
Fluttercon 2024: Showing that you care about security - OpenSSF Scorecards fo...
Fluttercon 2024: Showing that you care about security - OpenSSF Scorecards fo...Fluttercon 2024: Showing that you care about security - OpenSSF Scorecards fo...
Fluttercon 2024: Showing that you care about security - OpenSSF Scorecards fo...
Chris Swan
 
find out more about the role of autonomous vehicles in facing global challenges
find out more about the role of autonomous vehicles in facing global challengesfind out more about the role of autonomous vehicles in facing global challenges
find out more about the role of autonomous vehicles in facing global challenges
huseindihon
 
Implementations of Fused Deposition Modeling in real world
Implementations of Fused Deposition Modeling  in real worldImplementations of Fused Deposition Modeling  in real world
Implementations of Fused Deposition Modeling in real world
Emerging Tech
 
Quantum Communications Q&A with Gemini LLM
Quantum Communications Q&A with Gemini LLMQuantum Communications Q&A with Gemini LLM
Quantum Communications Q&A with Gemini LLM
Vijayananda Mohire
 
20240702 QFM021 Machine Intelligence Reading List June 2024
20240702 QFM021 Machine Intelligence Reading List June 202420240702 QFM021 Machine Intelligence Reading List June 2024
20240702 QFM021 Machine Intelligence Reading List June 2024
Matthew Sinclair
 
Best Programming Language for Civil Engineers
Best Programming Language for Civil EngineersBest Programming Language for Civil Engineers
Best Programming Language for Civil Engineers
Awais Yaseen
 
Recent Advancements in the NIST-JARVIS Infrastructure
Recent Advancements in the NIST-JARVIS InfrastructureRecent Advancements in the NIST-JARVIS Infrastructure
Recent Advancements in the NIST-JARVIS Infrastructure
KAMAL CHOUDHARY
 
What’s New in Teams Calling, Meetings and Devices May 2024
What’s New in Teams Calling, Meetings and Devices May 2024What’s New in Teams Calling, Meetings and Devices May 2024
What’s New in Teams Calling, Meetings and Devices May 2024
Stephanie Beckett
 
DealBook of Ukraine: 2024 edition
DealBook of Ukraine: 2024 editionDealBook of Ukraine: 2024 edition
DealBook of Ukraine: 2024 edition
Yevgen Sysoyev
 
INDIAN AIR FORCE FIGHTER PLANES LIST.pdf
INDIAN AIR FORCE FIGHTER PLANES LIST.pdfINDIAN AIR FORCE FIGHTER PLANES LIST.pdf
INDIAN AIR FORCE FIGHTER PLANES LIST.pdf
jackson110191
 
Research Directions for Cross Reality Interfaces
Research Directions for Cross Reality InterfacesResearch Directions for Cross Reality Interfaces
Research Directions for Cross Reality Interfaces
Mark Billinghurst
 
20240702 Présentation Plateforme GenAI.pdf
20240702 Présentation Plateforme GenAI.pdf20240702 Présentation Plateforme GenAI.pdf
20240702 Présentation Plateforme GenAI.pdf
Sally Laouacheria
 
Coordinate Systems in FME 101 - Webinar Slides
Coordinate Systems in FME 101 - Webinar SlidesCoordinate Systems in FME 101 - Webinar Slides
Coordinate Systems in FME 101 - Webinar Slides
Safe Software
 
Comparison Table of DiskWarrior Alternatives.pdf
Comparison Table of DiskWarrior Alternatives.pdfComparison Table of DiskWarrior Alternatives.pdf
Comparison Table of DiskWarrior Alternatives.pdf
Andrey Yasko
 

Recently uploaded (20)

Cookies program to display the information though cookie creation
Cookies program to display the information though cookie creationCookies program to display the information though cookie creation
Cookies program to display the information though cookie creation
 
How Social Media Hackers Help You to See Your Wife's Message.pdf
How Social Media Hackers Help You to See Your Wife's Message.pdfHow Social Media Hackers Help You to See Your Wife's Message.pdf
How Social Media Hackers Help You to See Your Wife's Message.pdf
 
Observability For You and Me with OpenTelemetry
Observability For You and Me with OpenTelemetryObservability For You and Me with OpenTelemetry
Observability For You and Me with OpenTelemetry
 
Choose our Linux Web Hosting for a seamless and successful online presence
Choose our Linux Web Hosting for a seamless and successful online presenceChoose our Linux Web Hosting for a seamless and successful online presence
Choose our Linux Web Hosting for a seamless and successful online presence
 
TrustArc Webinar - 2024 Data Privacy Trends: A Mid-Year Check-In
TrustArc Webinar - 2024 Data Privacy Trends: A Mid-Year Check-InTrustArc Webinar - 2024 Data Privacy Trends: A Mid-Year Check-In
TrustArc Webinar - 2024 Data Privacy Trends: A Mid-Year Check-In
 
論文紹介:A Systematic Survey of Prompt Engineering on Vision-Language Foundation ...
論文紹介:A Systematic Survey of Prompt Engineering on Vision-Language Foundation ...論文紹介:A Systematic Survey of Prompt Engineering on Vision-Language Foundation ...
論文紹介:A Systematic Survey of Prompt Engineering on Vision-Language Foundation ...
 
Fluttercon 2024: Showing that you care about security - OpenSSF Scorecards fo...
Fluttercon 2024: Showing that you care about security - OpenSSF Scorecards fo...Fluttercon 2024: Showing that you care about security - OpenSSF Scorecards fo...
Fluttercon 2024: Showing that you care about security - OpenSSF Scorecards fo...
 
find out more about the role of autonomous vehicles in facing global challenges
find out more about the role of autonomous vehicles in facing global challengesfind out more about the role of autonomous vehicles in facing global challenges
find out more about the role of autonomous vehicles in facing global challenges
 
Implementations of Fused Deposition Modeling in real world
Implementations of Fused Deposition Modeling  in real worldImplementations of Fused Deposition Modeling  in real world
Implementations of Fused Deposition Modeling in real world
 
Quantum Communications Q&A with Gemini LLM
Quantum Communications Q&A with Gemini LLMQuantum Communications Q&A with Gemini LLM
Quantum Communications Q&A with Gemini LLM
 
20240702 QFM021 Machine Intelligence Reading List June 2024
20240702 QFM021 Machine Intelligence Reading List June 202420240702 QFM021 Machine Intelligence Reading List June 2024
20240702 QFM021 Machine Intelligence Reading List June 2024
 
Best Programming Language for Civil Engineers
Best Programming Language for Civil EngineersBest Programming Language for Civil Engineers
Best Programming Language for Civil Engineers
 
Recent Advancements in the NIST-JARVIS Infrastructure
Recent Advancements in the NIST-JARVIS InfrastructureRecent Advancements in the NIST-JARVIS Infrastructure
Recent Advancements in the NIST-JARVIS Infrastructure
 
What’s New in Teams Calling, Meetings and Devices May 2024
What’s New in Teams Calling, Meetings and Devices May 2024What’s New in Teams Calling, Meetings and Devices May 2024
What’s New in Teams Calling, Meetings and Devices May 2024
 
DealBook of Ukraine: 2024 edition
DealBook of Ukraine: 2024 editionDealBook of Ukraine: 2024 edition
DealBook of Ukraine: 2024 edition
 
INDIAN AIR FORCE FIGHTER PLANES LIST.pdf
INDIAN AIR FORCE FIGHTER PLANES LIST.pdfINDIAN AIR FORCE FIGHTER PLANES LIST.pdf
INDIAN AIR FORCE FIGHTER PLANES LIST.pdf
 
Research Directions for Cross Reality Interfaces
Research Directions for Cross Reality InterfacesResearch Directions for Cross Reality Interfaces
Research Directions for Cross Reality Interfaces
 
20240702 Présentation Plateforme GenAI.pdf
20240702 Présentation Plateforme GenAI.pdf20240702 Présentation Plateforme GenAI.pdf
20240702 Présentation Plateforme GenAI.pdf
 
Coordinate Systems in FME 101 - Webinar Slides
Coordinate Systems in FME 101 - Webinar SlidesCoordinate Systems in FME 101 - Webinar Slides
Coordinate Systems in FME 101 - Webinar Slides
 
Comparison Table of DiskWarrior Alternatives.pdf
Comparison Table of DiskWarrior Alternatives.pdfComparison Table of DiskWarrior Alternatives.pdf
Comparison Table of DiskWarrior Alternatives.pdf
 

New Ways to Find Latency in Linux Using Tracing

  • 1. Brought to you by New ways to find latency in Linux using tracing Steven Rostedt Open Source Engineer at VMware
  • 2. ©2021 VMware, Inc. New ways to find latency in Linux using tracing Steven Rostedt Open Source Engineer srostedt@vmware.com twitter: @srostedt
  • 3. What is ftrace? ● Official tracer of the Linux Kernel – Introduced in 2008 ● Came from the PREEMPT_RT patch set – Initially focused on finding causes of latency ● Has grows significantly since 2008 – Added new ways to find latency – Does much more than find latency
  • 4. The ftrace interface (the tracefs file system) # mount -t tracefs nodev /sys/kernel/tracing # ls /sys/kernel/tracing available_events max_graph_depth snapshot available_filter_functions options stack_max_size available_tracers osnoise stack_trace buffer_percent per_cpu stack_trace_filter buffer_size_kb printk_formats synthetic_events buffer_total_size_kb README timestamp_mode current_tracer recursed_functions trace dynamic_events saved_cmdlines trace_clock dyn_ftrace_total_info saved_cmdlines_size trace_marker enabled_functions saved_tgids trace_marker_raw error_log set_event trace_options eval_map set_event_notrace_pid trace_pipe events set_event_pid trace_stat free_buffer set_ftrace_filter tracing_cpumask function_profile_enabled set_ftrace_notrace tracing_max_latency hwlat_detector set_ftrace_notrace_pid tracing_on instances set_ftrace_pid tracing_thresh kprobe_events set_graph_function uprobe_events kprobe_profile set_graph_notrace uprobe_profile
  • 5. Introducing trace-cmd Luckily today, we do not need to know all those files ● trace-cmd is a front end interface to ftrace ● It interfaces with the tracefs directory for you https://www.trace-cmd.org git clone git://git.kernel.org/pub/scm/utils/trace-cmd/trace-cmd.git
  • 6. The Old Tracers ● Wake up trace – All tasks – RT tasks – Deadline Tasks ● Preemption off tracers – irqsoff tracer – preemptoff tracer – preemptirqsoff tracer
  • 7. Wake up tracer Task 1 Interrupt Wake up Task 2 event Task 2 Sched switch event latency
  • 8. Running wakeup_rt tracer # trace-cmd start -p wakeup_rt # trace-cmd show # tracer: wakeup_rt # # wakeup_rt latency trace v1.1.5 on 5.10.52-test-rt47 # latency: 94 us, #211/211, CPU#4 | (M:preempt_rt VP:0, KP:0, SP:0 HP:0 #P:8) # ----------------- # | task: rcuc/4-42 (uid:0 nice:0 policy:1 rt_prio:1) # ----------------- # # _--------=> CPU# # / _-------=> irqs-off # | / _------=> need-resched # || / _-----=> need-resched-lazy # ||| / _----=> hardirq/softirq # |||| / _---=> preempt-depth # ||||| / _--=> preempt-lazy-depth # |||||| / _-=> migrate-disable # ||||||| / delay # cmd pid |||||||| time | caller # / |||||||| | / bash-1872 4dN.h5.. 1us+: 1872:120:R + [004] 42: 98:R rcuc/4 bash-1872 4dN.h5.. 30us : <stack trace> => __ftrace_trace_stack => probe_wakeup => ttwu_do_wakeup => try_to_wake_up
  • 9. Running wakeup_rt tracer => invoke_rcu_core => rcu_sched_clock_irq => update_process_times => tick_sched_handle => tick_sched_timer => __hrtimer_run_queues => hrtimer_interrupt => __sysvec_apic_timer_interrupt => asm_call_irq_on_stack => sysvec_apic_timer_interrupt => asm_sysvec_apic_timer_interrupt => lock_acquire => _raw_spin_lock => shmem_get_inode => shmem_mknod => lookup_open.isra.0 => path_openat => do_filp_open => do_sys_openat2 => __x64_sys_openat => do_syscall_64 => entry_SYSCALL_64_after_hwframe bash-1872 4dN.h5.. 31us : 0 bash-1872 4dN.h4.. 32us : task_woken_rt ←ttwu_do_wakeup bash-1872 4dN..2.. 87us : put_prev_entity <-put_prev_task_fair bash-1872 4dN..2.. 87us : update_curr <-put_prev_entity bash-1872 4dN..2.. 87us : __update_load_avg_se <-update_load_avg bash-1872 4dN..2.. 87us : __update_load_avg_cfs_rq <-update_load_avg
  • 10. Running wakeup_rt tracer bash-1872 4dN..2.. 87us : pick_next_task_stop <-__schedule bash-1872 4dN..2.. 87us : pick_next_task_dl <-__schedule bash-1872 4dN..2.. 87us : pick_next_task_rt <-__schedule bash-1872 4dN..2.. 88us : update_rt_rq_load_avg <-pick_next_task_rt bash-1872 4d...3.. 88us : __schedule bash-1872 4d...3.. 88us : 1872:120:R ==> [004] 42: 98:R rcuc/4 bash-1872 4d...3.. 94us : <stack trace> => __ftrace_trace_stack => probe_wakeup_sched_switch => __schedule => preempt_schedule_common => preempt_schedule_thunk => _raw_spin_unlock => shmem_get_inode => shmem_mknod => lookup_open.isra.0 => path_openat => do_filp_open => do_sys_openat2 => __x64_sys_openat => do_syscall_64 => entry_SYSCALL_64_after_hwframe
  • 11. Interrupt off tracer Task Interrupt Irqs disabled latency Irqs enabled
  • 12. Running preemptirqsoff tracer # trace-cmd start -p preemptirqsoff # trace-cmd show # tracer: preemptirqsoff # # preemptirqsoff latency trace v1.1.5 on 5.14.0-rc4-test+ # -------------------------------------------------------------------- # latency: 2325 us, #3005/3005, CPU#1 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:8) # ----------------- # | task: bash-48651 (uid:0 nice:0 policy:0 rt_prio:0) # ----------------- # => started at: _raw_spin_lock # => ended at: _raw_spin_unlock # # # _------=> CPU# # / _-----=> irqs-off # | / _----=> need-resched # || / _---=> hardirq/softirq # ||| / _--=> preempt-depth # |||| / delay # cmd pid ||||| time | caller # / ||||| | / trace-cm-48651 1...1 0us : _raw_spin_lock trace-cm-48651 1...1 1us : do_raw_spin_trylock <-_raw_spin_lock trace-cm-48651 1...1 1us : flush_tlb_batched_pending <-unmap_page_range trace-cm-48651 1...1 2us : vm_normal_page <-unmap_page_range trace-cm-48651 1...1 2us : page_remove_rmap <-unmap_page_range
  • 13. Running preemptirqsoff tracer [...] trace-cm-48651 1...1 2313us : unlock_page_memcg <-unmap_page_range trace-cm-48651 1...1 2314us : __rcu_read_unlock <-unlock_page_memcg trace-cm-48651 1...1 2315us : __tlb_remove_page_size <-unmap_page_range trace-cm-48651 1...1 2316us : vm_normal_page <-unmap_page_range trace-cm-48651 1...1 2317us : page_remove_rmap <-unmap_page_range trace-cm-48651 1...1 2318us : lock_page_memcg <-page_remove_rmap trace-cm-48651 1...1 2318us : __rcu_read_lock <-lock_page_memcg trace-cm-48651 1...1 2319us : unlock_page_memcg <-unmap_page_range trace-cm-48651 1...1 2320us : __rcu_read_unlock <-unlock_page_memcg trace-cm-48651 1...1 2321us : __tlb_remove_page_size <-unmap_page_range trace-cm-48651 1...1 2322us : _raw_spin_unlock <-unmap_page_range trace-cm-48651 1...1 2323us : do_raw_spin_unlock <-_raw_spin_unlock trace-cm-48651 1...1 2324us : preempt_count_sub <-_raw_spin_unlock trace-cm-48651 1...1 2325us : _raw_spin_unlock trace-cm-48651 1...1 2327us+: tracer_preempt_on <-_raw_spin_unlock trace-cm-48651 1...1 2343us : <stack trace> => unmap_page_range => unmap_vmas => exit_mmap => mmput => begin_new_exec => load_elf_binary => bprm_execve => do_execveat_common => __x64_sys_execve => do_syscall_64 => entry_SYSCALL_64_after_hwframe
  • 14. Running preemptirqsoff tracer # trace-cmd start -p preemptirqsoff -d -O sym-offset # trace-cmd show # tracer: preemptirqsoff [..] # latency: 248 us, #4/4, CPU#6 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:8) # ----------------- # | task: ksoftirqd/6-47 (uid:0 nice:0 policy:0 rt_prio:0) # ----------------- # => started at: run_ksoftirqd # => ended at: run_ksoftirqd [..] # cmd pid ||||| time | caller # / ||||| | / <idle>-0 4d..1 1us!: cpuidle_enter_state+0xcf/0x410 kworker/-48096 4...1 242us : schedule+0x4d/0xe0 <-schedule+0x4d/0xe0 kworker/-48096 4...1 243us : tracer_preempt_on+0xf4/0x110 <-schedule+0x4d/0xe0 kworker/-48096 4...1 248us : <stack trace> => worker_thread+0xd4/0x3c0 => kthread+0x155/0x180 => ret_from_fork+0x22/0x30
  • 16. Measuring latency from interrupts ● You can easily trace the latency from interrupts – For x86: # trace-cmd record -p function_graph -l handle_irq_event -l ‘*sysvec_*’ -e irq_handler_entry -e 'irq_vectors:*entry*'
  • 17. Tracing Latency from Interrupts # trace-cmd report -l --cpu 2 sleep-2513 [002] 2973.197184: funcgraph_entry: | __sysvec_apic_timer_interrupt() { sleep-2513 [002] 2973.197186: local_timer_entry: vector=236 sleep-2513 [002] 2973.197196: funcgraph_exit: + 12.233 us | } sleep-2513 [002] 2973.197206: funcgraph_entry: | __sysvec_irq_work() { sleep-2513 [002] 2973.197207: irq_work_entry: vector=246 sleep-2513 [002] 2973.197207: funcgraph_exit: 1.405 us | } <idle>-0 [002] 2973.198186: funcgraph_entry: | __sysvec_apic_timer_interrupt() { <idle>-0 [002] 2973.198187: local_timer_entry: vector=236 <idle>-0 [002] 2973.198193: funcgraph_exit: 7.992 us | } <idle>-0 [002] 2974.991721: funcgraph_entry: | handle_irq_event() { <idle>-0 [002] 2974.991723: irq_handler_entry: irq=24 name=ahci[0000:00:1f.2] <idle>-0 [002] 2974.991733: funcgraph_exit: + 13.158 us | } <idle>-0 [002] 2977.039843: funcgraph_entry: | handle_irq_event() { <idle>-0 [002] 2977.039845: irq_handler_entry: irq=24 name=ahci[0000:00:1f.2] <idle>-0 [002] 2977.039855: funcgraph_exit: + 12.869 us | }
  • 18. Problems with the latency tracers ● No control over what tasks they trace – They trace the highest priority process – May not be the process you are interested in ● Not flexible – Has one use case – General for the entire system
  • 19. Tracing interrupt latency with function graph tracer ● Does not have a “max latency” – You see all the latency in a trace – No way to record the max latency found
  • 20. Introducing Synthetic Events ● Can map two events into a single event
  • 21. Introducing Synthetic Events ● Can map two events into a single event – sched_waking + sched_switch wakeup_latency → – irqs_disabled + irqs_enabled irqs_off_latency → – irq_enter_handler + irq_exit_handler irq_latency →
  • 22. Introducing Synthetic Events ● Can map two events into a single event – sched_waking + sched_switch wakeup_latency → – irqs_disabled + irqs_enabled irqs_off_latency → – irq_enter_handler + irq_exit_handler irq_latency → ● Have all the functionality as a normal event
  • 23. Introducing Synthetic Events ● Can map two events into a single event – sched_waking + sched_switch wakeup_latency → – irqs_disabled + irqs_enabled irqs_off_latency → – irq_enter_handler + irq_exit_handler irq_latency → ● Have all the functionality as a normal event – Can be filtered on
  • 24. Introducing Synthetic Events ● Can map two events into a single event – sched_waking + sched_switch wakeup_latency → – irqs_disabled + irqs_enabled irqs_off_latency → – irq_enter_handler + irq_exit_handler irq_latency → ● Have all the functionality as a normal event – Can be filtered on – Can have triggers attached (like histograms)
  • 25. Synthetic events # echo 'wakeup_lat s32 pid; u64 delta;' > /sys/kernel/tracing/synthetic_events # echo 'hist:keys=pid:__arg__1=pid,__arg__2=common_timestamp.usecs' > /sys/kernel/tracing/events/sched/sched_waking/trigger # echo 'hist:keys=next_pid:pid=$__arg__1,’ ‘delta=common_timestamp.usecs-$__arg__2:onmatch(sched.sched_waking)’ ‘.trace(wakeup_lat,$pid,$delta) if next_comm == “cyclictest”' > /sys/kernel/tracing/events/sched/sched_switch/trigger
  • 26. Synthetic events # echo 'wakeup_lat s32 pid; u64 delta;' > /sys/kernel/tracing/synthetic_events # echo 'hist:keys=pid:__arg__1=pid,__arg__2=common_timestamp.usecs' > /sys/kernel/tracing/events/sched/sched_waking/trigger # echo 'hist:keys=next_pid:pid=$__arg__1,’ ‘delta=common_timestamp.usecs-$__arg__2:onmatch(sched.sched_waking)’ ‘.trace(wakeup_lat,$pid,$delta) if next_comm == “cyclictest”' > /sys/kernel/tracing/events/sched/sched_switch/trigger Too Complex!
  • 27. Introducing libtracefs A library to interact with the tracefs file system All functions have man pages The tracefs_sql man page has the sqlhist program in it https://git.kernel.org/pub/scm/libs/libtrace/libtracefs.git/ git clone git://git.kernel.org/pub/scm/libs/libtrace/libtracefs.git cd libtracefs make sqlhist # builds from the man page!
  • 28. Synthetic events # sqlhist -e -n wakeup_lat ‘SELECT start.pid, (end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS delta FROM ’ ‘sched_waking AS start JOIN sched_switch AS end ON start.pid = end.next_pid' ‘WHERE end.next_pid = “cyclictest”’
  • 29. Synthetic events # sqlhist -e -n wakeup_lat ‘SELECT start.pid, (end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS delta FROM ’ ‘sched_waking AS start JOIN sched_switch AS end ON start.pid = end.next_pid' ‘WHERE end.next_pid = “cyclictest”’
  • 30. Synthetic events # sqlhist -e -n wakeup_lat ‘SELECT start.pid, (end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS delta FROM ’ ‘sched_waking AS start JOIN sched_switch AS end ON start.pid = end.next_pid' ‘WHERE end.next_pid = “cyclictest”’
  • 31. Synthetic events # sqlhist -e -n wakeup_lat ‘SELECT start.pid, (end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS delta FROM ’ ‘sched_waking AS start JOIN sched_switch AS end ON start.pid = end.next_pid' ‘WHERE end.next_pid = “cyclictest”’
  • 32. Synthetic events # sqlhist -e -n wakeup_lat ‘SELECT start.pid, (end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS delta FROM ’ ‘sched_waking AS start JOIN sched_switch AS end ON start.pid = end.next_pid' ‘WHERE end.next_pid = “cyclictest”’
  • 33. Synthetic events # sqlhist -e -n wakeup_lat ‘SELECT start.pid, (end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS delta FROM ’ ‘sched_waking AS start JOIN sched_switch AS end ON start.pid = end.next_pid' ‘WHERE end.next_pid = “cyclictest”’
  • 34. Synthetic events # sqlhist -e -n wakeup_lat ‘SELECT start.pid, (end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS delta FROM ’ ‘sched_waking AS start JOIN sched_switch AS end ON start.pid = end.next_pid' ‘WHERE end.next_pid = “cyclictest”’
  • 35. Synthetic events # sqlhist -e -n wakeup_lat ‘SELECT start.pid, (end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS delta FROM ’ ‘sched_waking AS start JOIN sched_switch AS end ON start.pid = end.next_pid' ‘WHERE end.next_pid = “cyclictest”’
  • 36. Synthetic events # sqlhist -e -n wakeup_lat ‘SELECT start.pid, (end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS delta FROM ’ ‘sched_waking AS start JOIN sched_switch AS end ON start.pid = end.next_pid' ‘WHERE end.next_pid = “cyclictest”’
  • 37. cyclictest A tool used by real-time developers to test wake up latency in the system https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git/ git clone git://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git cd rt-tests make cyclictest
  • 38. Customize latency tracing # sqlhist -e -n wakeup_lat -T -m lat 'SELECT end.next_comm AS comm, ’ ‘(end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS lat ’ ‘FROM sched_waking AS start JOIN sched_switch AS end ’ ‘ON start.pid = end.next_pid’ ‘WHERE end.next_prio < 100 && end.next_comm == "cyclictest"' # trace-cmd start -e all -e wakeup_lat -R stacktrace # cyclictest -l 1000 -p80 -i250 -a -t -q -m -d 0 -b 1000 --tracemark # trace-cmd show -s | tail -16 <idle>-0 [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1 <idle>-0 [002] d..2 23454.902254: sched_switch: prev_comm=swapper/2 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=cyclictest next_pid=12275 next_prio=19 <idle>-0 [002] d..4 23454.902256: wakeup_lat: next_comm=cyclictest lat=17 <idle>-0 [002] d..5 23454.902258: <stack trace> => trace_event_raw_event_synth => action_trace => event_hist_trigger => event_triggers_call => trace_event_buffer_commit => trace_event_raw_event_sched_switch => __traceiter_sched_switch => __schedule => schedule_idle => do_idle => cpu_startup_entry => secondary_startup_64_no_verify
  • 39. Customize latency tracing # sqlhist -e -n wakeup_lat -T -m lat 'SELECT end.next_comm AS comm, ’ ‘(end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS lat ’ ‘FROM sched_waking AS start JOIN sched_switch AS end ’ ‘ON start.pid = end.next_pid’ ‘WHERE end.next_prio < 100 && end.next_comm == "cyclictest"' # trace-cmd start -e all -e wakeup_lat -R stacktrace # cyclictest -l 1000 -p80 -i250 -a -t -q -m -d 0 -b 1000 --tracemark # trace-cmd show -s | tail -16 <idle>-0 [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1 <idle>-0 [002] d..2 23454.902254: sched_switch: prev_comm=swapper/2 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=cyclictest next_pid=12275 next_prio=19 <idle>-0 [002] d..4 23454.902256: wakeup_lat: next_comm=cyclictest lat=17 <idle>-0 [002] d..5 23454.902258: <stack trace> => trace_event_raw_event_synth => action_trace => event_hist_trigger => event_triggers_call => trace_event_buffer_commit => trace_event_raw_event_sched_switch => __traceiter_sched_switch => __schedule => schedule_idle => do_idle => cpu_startup_entry => secondary_startup_64_no_verify
  • 40. Customize latency tracing # sqlhist -e -n wakeup_lat -T -m lat 'SELECT end.next_comm AS comm, ’ ‘(end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS lat ’ ‘FROM sched_waking AS start JOIN sched_switch AS end ’ ‘ON start.pid = end.next_pid’ ‘WHERE end.next_prio < 100 && end.next_comm == "cyclictest"' # trace-cmd start -e all -e wakeup_lat -R stacktrace # cyclictest -l 1000 -p80 -i250 -a -t -q -m -d 0 -b 1000 --tracemark # trace-cmd show -s | tail -16 <idle>-0 [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1 <idle>-0 [002] d..2 23454.902254: sched_switch: prev_comm=swapper/2 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=cyclictest next_pid=12275 next_prio=19 <idle>-0 [002] d..4 23454.902256: wakeup_lat: next_comm=cyclictest lat=17 <idle>-0 [002] d..5 23454.902258: <stack trace> => trace_event_raw_event_synth => action_trace => event_hist_trigger => event_triggers_call => trace_event_buffer_commit => trace_event_raw_event_sched_switch => __traceiter_sched_switch => __schedule => schedule_idle => do_idle => cpu_startup_entry => secondary_startup_64_no_verify
  • 41. Customize latency tracing # sqlhist -e -n wakeup_lat -T -m lat 'SELECT end.next_comm AS comm, ’ ‘(end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS lat ’ ‘FROM sched_waking AS start JOIN sched_switch AS end ’ ‘ON start.pid = end.next_pid’ ‘WHERE end.next_prio < 100 && end.next_comm == "cyclictest"' # trace-cmd start -e all -e wakeup_lat -R stacktrace # cyclictest -l 1000 -p80 -i250 -a -t -q -m -d 0 -b 1000 --tracemark # trace-cmd show -s | tail -16 <idle>-0 [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1 <idle>-0 [002] d..2 23454.902254: sched_switch: prev_comm=swapper/2 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=cyclictest next_pid=12275 next_prio=19 <idle>-0 [002] d..4 23454.902256: wakeup_lat: next_comm=cyclictest lat=17 <idle>-0 [002] d..5 23454.902258: <stack trace> => trace_event_raw_event_synth => action_trace => event_hist_trigger => event_triggers_call => trace_event_buffer_commit => trace_event_raw_event_sched_switch => __traceiter_sched_switch => __schedule => schedule_idle => do_idle => cpu_startup_entry => secondary_startup_64_no_verify
  • 42. Customize latency tracing # sqlhist -e -n wakeup_lat -T -m lat 'SELECT end.next_comm AS comm, ’ ‘(end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS lat ’ ‘FROM sched_waking AS start JOIN sched_switch AS end ’ ‘ON start.pid = end.next_pid’ ‘WHERE end.next_prio < 100 && end.next_comm == "cyclictest"' # trace-cmd start -e all -e wakeup_lat -R stacktrace # cyclictest -l 1000 -p80 -i250 -a -t -q -m -d 0 -b 1000 --tracemark # trace-cmd show -s | tail -16 <idle>-0 [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1 <idle>-0 [002] d..2 23454.902254: sched_switch: prev_comm=swapper/2 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=cyclictest next_pid=12275 next_prio=19 <idle>-0 [002] d..4 23454.902256: wakeup_lat: next_comm=cyclictest lat=17 <idle>-0 [002] d..5 23454.902258: <stack trace> => trace_event_raw_event_synth => action_trace => event_hist_trigger => event_triggers_call => trace_event_buffer_commit => trace_event_raw_event_sched_switch => __traceiter_sched_switch => __schedule => schedule_idle => do_idle => cpu_startup_entry => secondary_startup_64_no_verify
  • 43. Customize latency tracing # sqlhist -e -n wakeup_lat -T -m lat 'SELECT end.next_comm AS comm, ’ ‘(end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS lat ’ ‘FROM sched_waking AS start JOIN sched_switch AS end ’ ‘ON start.pid = end.next_pid’ ‘WHERE end.next_prio < 100 && end.next_comm == "cyclictest"' # trace-cmd start -e all -e wakeup_lat -R stacktrace # cyclictest -l 1000 -p80 -i250 -a -t -q -m -d 0 -b 1000 --tracemark # trace-cmd show -s | tail -16 <idle>-0 [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1 <idle>-0 [002] d..2 23454.902254: sched_switch: prev_comm=swapper/2 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=cyclictest next_pid=12275 next_prio=19 <idle>-0 [002] d..4 23454.902256: wakeup_lat: next_comm=cyclictest lat=17 <idle>-0 [002] d..5 23454.902258: <stack trace> => trace_event_raw_event_synth => action_trace => event_hist_trigger => event_triggers_call => trace_event_buffer_commit => trace_event_raw_event_sched_switch => __traceiter_sched_switch => __schedule => schedule_idle => do_idle => cpu_startup_entry => secondary_startup_64_no_verify
  • 44. Customize latency tracing # sqlhist -e -n wakeup_lat -T -m lat 'SELECT end.next_comm AS comm, ’ ‘(end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS lat ’ ‘FROM sched_waking AS start JOIN sched_switch AS end ’ ‘ON start.pid = end.next_pid’ ‘WHERE end.next_prio < 100 && end.next_comm == "cyclictest"' # trace-cmd start -e all -e wakeup_lat -R stacktrace # cyclictest -l 1000 -p80 -i250 -a -t -q -m -d 0 -b 1000 --tracemark # trace-cmd show -s | tail -16 <idle>-0 [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1 <idle>-0 [002] d..2 23454.902254: sched_switch: prev_comm=swapper/2 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=cyclictest next_pid=12275 next_prio=19 <idle>-0 [002] d..4 23454.902256: wakeup_lat: next_comm=cyclictest lat=17 <idle>-0 [002] d..5 23454.902258: <stack trace> => trace_event_raw_event_synth => action_trace => event_hist_trigger => event_triggers_call => trace_event_buffer_commit => trace_event_raw_event_sched_switch => __traceiter_sched_switch => __schedule => schedule_idle => do_idle => cpu_startup_entry => secondary_startup_64_no_verify
  • 45. Customize latency tracing # sqlhist -e -n wakeup_lat -T -m lat 'SELECT end.next_comm AS comm, ’ ‘(end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS lat ’ ‘FROM sched_waking AS start JOIN sched_switch AS end ’ ‘ON start.pid = end.next_pid’ ‘WHERE end.next_prio < 100 && end.next_comm == "cyclictest"' # trace-cmd start -e all -e wakeup_lat -R stacktrace # cyclictest -l 1000 -p80 -i250 -a -t -q -m -d 0 -b 1000 --tracemark # trace-cmd show -s | tail -16 <idle>-0 [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1 <idle>-0 [002] d..2 23454.902254: sched_switch: prev_comm=swapper/2 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=cyclictest next_pid=12275 next_prio=19 <idle>-0 [002] d..4 23454.902256: wakeup_lat: next_comm=cyclictest lat=17 <idle>-0 [002] d..5 23454.902258: <stack trace> => trace_event_raw_event_synth => action_trace => event_hist_trigger => event_triggers_call => trace_event_buffer_commit => trace_event_raw_event_sched_switch => __traceiter_sched_switch => __schedule => schedule_idle => do_idle => cpu_startup_entry => secondary_startup_64_no_verify
  • 46. Customize latency tracing # sqlhist -e -n wakeup_lat -T -m lat 'SELECT end.next_comm AS comm, ’ ‘(end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS lat ’ ‘FROM sched_waking AS start JOIN sched_switch AS end ’ ‘ON start.pid = end.next_pid’ ‘WHERE end.next_prio < 100 && end.next_comm == "cyclictest"' # trace-cmd start -e all -e wakeup_lat -R stacktrace # cyclictest -l 1000 -p80 -i250 -a -t -q -m -d 0 -b 1000 --tracemark # trace-cmd show -s | tail -16 <idle>-0 [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1 <idle>-0 [002] d..2 23454.902254: sched_switch: prev_comm=swapper/2 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=cyclictest next_pid=12275 next_prio=19 <idle>-0 [002] d..4 23454.902256: wakeup_lat: next_comm=cyclictest lat=17 <idle>-0 [002] d..5 23454.902258: <stack trace> => trace_event_raw_event_synth => action_trace => event_hist_trigger => event_triggers_call => trace_event_buffer_commit => trace_event_raw_event_sched_switch => __traceiter_sched_switch => __schedule => schedule_idle => do_idle => cpu_startup_entry => secondary_startup_64_no_verify
  • 47. Customize latency tracing # sqlhist -e -n wakeup_lat -T -m lat 'SELECT end.next_comm AS comm, ’ ‘(end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS lat ’ ‘FROM sched_waking AS start JOIN sched_switch AS end ’ ‘ON start.pid = end.next_pid’ ‘WHERE end.next_prio < 100 && end.next_comm == "cyclictest"' # trace-cmd start -e all -e wakeup_lat -R stacktrace # cyclictest -l 1000 -p80 -i250 -a -t -q -m -d 0 -b 1000 --tracemark # trace-cmd show -s | tail -16 <idle>-0 [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1 <idle>-0 [002] d..2 23454.902254: sched_switch: prev_comm=swapper/2 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=cyclictest next_pid=12275 next_prio=19 <idle>-0 [002] d..4 23454.902256: wakeup_lat: next_comm=cyclictest lat=17 <idle>-0 [002] d..5 23454.902258: <stack trace> => trace_event_raw_event_synth => action_trace => event_hist_trigger => event_triggers_call => trace_event_buffer_commit => trace_event_raw_event_sched_switch => __traceiter_sched_switch => __schedule => schedule_idle => do_idle => cpu_startup_entry => secondary_startup_64_no_verify
  • 48. Customize latency tracing # sqlhist -e -n wakeup_lat -T -m lat 'SELECT end.next_comm AS comm, ’ ‘(end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS lat ’ ‘FROM sched_waking AS start JOIN sched_switch AS end ’ ‘ON start.pid = end.next_pid’ ‘WHERE end.next_prio < 100 && end.next_comm == "cyclictest"' # trace-cmd start -e all -e wakeup_lat -R stacktrace # cyclictest -l 1000 -p80 -i250 -a -t -q -m -d 0 -b 1000 --tracemark # trace-cmd show -s | tail -16 <idle>-0 [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1 <idle>-0 [002] d..2 23454.902254: sched_switch: prev_comm=swapper/2 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=cyclictest next_pid=12275 next_prio=19 <idle>-0 [002] d..4 23454.902256: wakeup_lat: next_comm=cyclictest lat=17 <idle>-0 [002] d..5 23454.902258: <stack trace> => trace_event_raw_event_synth => action_trace => event_hist_trigger => event_triggers_call => trace_event_buffer_commit => trace_event_raw_event_sched_switch => __traceiter_sched_switch => __schedule => schedule_idle => do_idle => cpu_startup_entry => secondary_startup_64_no_verify
  • 49. Customize latency tracing # sqlhist -e -n wakeup_lat -T -m lat 'SELECT end.next_comm AS comm, ’ ‘(end.TIMESTAMP_USECS - start.TIMESTAMP_USECS) AS lat ’ ‘FROM sched_waking AS start JOIN sched_switch AS end ’ ‘ON start.pid = end.next_pid’ ‘WHERE end.next_prio < 100 && end.next_comm == "cyclictest"' # trace-cmd start -e all -e wakeup_lat -R stacktrace # cyclictest -l 1000 -p80 -i250 -a -t -q -m -d 0 -b 1000 --tracemark # trace-cmd show -s | tail -16 <idle>-0 [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1 <idle>-0 [002] d..2 23454.902254: sched_switch: prev_comm=swapper/2 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=cyclictest next_pid=12275 next_prio=19 <idle>-0 [002] d..4 23454.902256: wakeup_lat: next_comm=cyclictest lat=17 <idle>-0 [002] d..5 23454.902258: <stack trace> => trace_event_raw_event_synth => action_trace => event_hist_trigger => event_triggers_call => trace_event_buffer_commit => trace_event_raw_event_sched_switch => __traceiter_sched_switch => __schedule => schedule_idle => do_idle => cpu_startup_entry => secondary_startup_64_no_verify
  • 50. Customize latency tracing # trace-cmd extract -s # trace-cmd report --cpu 2 | tail -30 <idle>-0 [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1 <idle>-0 [002] 23454.902239: sched_wakeup: cyclictest:12275 [19] CPU:002 <idle>-0 [002] 23454.902241: hrtimer_expire_exit: hrtimer=0xffffbbd68286fe60 <idle>-0 [002] 23454.902241: hrtimer_cancel: hrtimer=0xffffbbd6826efe70 <idle>-0 [002] 23454.902242: hrtimer_expire_entry: hrtimer=0xffffbbd6826efe70 <idle>-0 [002] 23454.902243: sched_waking: comm=cyclictest pid=12272 prio=120 target_cpu=002 <idle>-0 [002] 23454.902244: prandom_u32: ret=1102749734 <idle>-0 [002] 23454.902246: sched_wakeup: cyclictest:12272 [120] CPU:002 <idle>-0 [002] 23454.902247: hrtimer_expire_exit: hrtimer=0xffffbbd6826efe70 <idle>-0 [002] 23454.902248: write_msr: 6e0, value 4866ce957272 <idle>-0 [002] 23454.902249: local_timer_exit: vector=236 <idle>-0 [002] 23454.902250: cpu_idle: state=4294967295 cpu_id=2 <idle>-0 [002] 23454.902251: rcu_utilization: Start context switch <idle>-0 [002] 23454.902252: rcu_utilization: End context switch <idle>-0 [002] 23454.902253: prandom_u32: ret=3692516021 <idle>-0 [002] 23454.902254: sched_switch: swapper/2:0 [120] R ==> cyclictest:12275 [19] <idle>-0 [002] 23454.902256: wakeup_lat: next_comm=cyclictest lat=17 <idle>-0 [002] 23454.902258: kernel_stack: <stack trace > => trace_event_raw_event_synth (ffffffff8121a0db) => action_trace (ffffffff8121e9fb) => event_hist_trigger (ffffffff8121ca8d) => event_triggers_call (ffffffff81216c72) [..]
  • 51. Customize latency tracing # trace-cmd extract -s # trace-cmd report --cpu 2 | tail -30 <idle>-0 [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1 <idle>-0 [002] 23454.902239: sched_wakeup: cyclictest:12275 [19] CPU:002 <idle>-0 [002] 23454.902241: hrtimer_expire_exit: hrtimer=0xffffbbd68286fe60 <idle>-0 [002] 23454.902241: hrtimer_cancel: hrtimer=0xffffbbd6826efe70 <idle>-0 [002] 23454.902242: hrtimer_expire_entry: hrtimer=0xffffbbd6826efe70 <idle>-0 [002] 23454.902243: sched_waking: comm=cyclictest pid=12272 prio=120 target_cpu=002 <idle>-0 [002] 23454.902244: prandom_u32: ret=1102749734 <idle>-0 [002] 23454.902246: sched_wakeup: cyclictest:12272 [120] CPU:002 <idle>-0 [002] 23454.902247: hrtimer_expire_exit: hrtimer=0xffffbbd6826efe70 <idle>-0 [002] 23454.902248: write_msr: 6e0, value 4866ce957272 <idle>-0 [002] 23454.902249: local_timer_exit: vector=236 <idle>-0 [002] 23454.902250: cpu_idle: state=4294967295 cpu_id=2 <idle>-0 [002] 23454.902251: rcu_utilization: Start context switch <idle>-0 [002] 23454.902252: rcu_utilization: End context switch <idle>-0 [002] 23454.902253: prandom_u32: ret=3692516021 <idle>-0 [002] 23454.902254: sched_switch: swapper/2:0 [120] R ==> cyclictest:12275 [19] <idle>-0 [002] 23454.902256: wakeup_lat: next_comm=cyclictest lat=17 <idle>-0 [002] 23454.902258: kernel_stack: <stack trace > => trace_event_raw_event_synth (ffffffff8121a0db) => action_trace (ffffffff8121e9fb) => event_hist_trigger (ffffffff8121ca8d) => event_triggers_call (ffffffff81216c72) [..]
  • 52. Customize latency tracing # trace-cmd extract -s # trace-cmd report --cpu 2 | tail -30 <idle>-0 [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1 <idle>-0 [002] 23454.902239: sched_wakeup: cyclictest:12275 [19] CPU:002 <idle>-0 [002] 23454.902241: hrtimer_expire_exit: hrtimer=0xffffbbd68286fe60 <idle>-0 [002] 23454.902241: hrtimer_cancel: hrtimer=0xffffbbd6826efe70 <idle>-0 [002] 23454.902242: hrtimer_expire_entry: hrtimer=0xffffbbd6826efe70 <idle>-0 [002] 23454.902243: sched_waking: comm=cyclictest pid=12272 prio=120 target_cpu=002 <idle>-0 [002] 23454.902244: prandom_u32: ret=1102749734 <idle>-0 [002] 23454.902246: sched_wakeup: cyclictest:12272 [120] CPU:002 <idle>-0 [002] 23454.902247: hrtimer_expire_exit: hrtimer=0xffffbbd6826efe70 <idle>-0 [002] 23454.902248: write_msr: 6e0, value 4866ce957272 <idle>-0 [002] 23454.902249: local_timer_exit: vector=236 <idle>-0 [002] 23454.902250: cpu_idle: state=4294967295 cpu_id=2 <idle>-0 [002] 23454.902251: rcu_utilization: Start context switch <idle>-0 [002] 23454.902252: rcu_utilization: End context switch <idle>-0 [002] 23454.902253: prandom_u32: ret=3692516021 <idle>-0 [002] 23454.902254: sched_switch: swapper/2:0 [120] R ==> cyclictest:12275 [19] <idle>-0 [002] 23454.902256: wakeup_lat: next_comm=cyclictest lat=17 <idle>-0 [002] 23454.902258: kernel_stack: <stack trace > => trace_event_raw_event_synth (ffffffff8121a0db) => action_trace (ffffffff8121e9fb) => event_hist_trigger (ffffffff8121ca8d) => event_triggers_call (ffffffff81216c72) [..]
  • 53. Customize latency tracing # trace-cmd extract -s # trace-cmd report --cpu 2 | tail -30 <idle>-0 [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1 <idle>-0 [002] 23454.902239: sched_wakeup: cyclictest:12275 [19] CPU:002 <idle>-0 [002] 23454.902241: hrtimer_expire_exit: hrtimer=0xffffbbd68286fe60 <idle>-0 [002] 23454.902241: hrtimer_cancel: hrtimer=0xffffbbd6826efe70 <idle>-0 [002] 23454.902242: hrtimer_expire_entry: hrtimer=0xffffbbd6826efe70 <idle>-0 [002] 23454.902243: sched_waking: comm=cyclictest pid=12272 prio=120 target_cpu=002 <idle>-0 [002] 23454.902244: prandom_u32: ret=1102749734 <idle>-0 [002] 23454.902246: sched_wakeup: cyclictest:12272 [120] CPU:002 <idle>-0 [002] 23454.902247: hrtimer_expire_exit: hrtimer=0xffffbbd6826efe70 <idle>-0 [002] 23454.902248: write_msr: 6e0, value 4866ce957272 <idle>-0 [002] 23454.902249: local_timer_exit: vector=236 <idle>-0 [002] 23454.902250: cpu_idle: state=4294967295 cpu_id=2 <idle>-0 [002] 23454.902251: rcu_utilization: Start context switch <idle>-0 [002] 23454.902252: rcu_utilization: End context switch <idle>-0 [002] 23454.902253: prandom_u32: ret=3692516021 <idle>-0 [002] 23454.902254: sched_switch: swapper/2:0 [120] R ==> cyclictest:12275 [19] <idle>-0 [002] 23454.902256: wakeup_lat: next_comm=cyclictest lat=17 <idle>-0 [002] 23454.902258: kernel_stack: <stack trace > => trace_event_raw_event_synth (ffffffff8121a0db) => action_trace (ffffffff8121e9fb) => event_hist_trigger (ffffffff8121ca8d) => event_triggers_call (ffffffff81216c72) [..]
  • 54. Customize latency tracing # trace-cmd extract -s # trace-cmd report --cpu 2 | tail -30 <idle>-0 [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1 <idle>-0 [002] 23454.902239: sched_wakeup: cyclictest:12275 [19] CPU:002 <idle>-0 [002] 23454.902241: hrtimer_expire_exit: hrtimer=0xffffbbd68286fe60 <idle>-0 [002] 23454.902241: hrtimer_cancel: hrtimer=0xffffbbd6826efe70 <idle>-0 [002] 23454.902242: hrtimer_expire_entry: hrtimer=0xffffbbd6826efe70 <idle>-0 [002] 23454.902243: sched_waking: comm=cyclictest pid=12272 prio=120 target_cpu=002 <idle>-0 [002] 23454.902244: prandom_u32: ret=1102749734 <idle>-0 [002] 23454.902246: sched_wakeup: cyclictest:12272 [120] CPU:002 <idle>-0 [002] 23454.902247: hrtimer_expire_exit: hrtimer=0xffffbbd6826efe70 <idle>-0 [002] 23454.902248: write_msr: 6e0, value 4866ce957272 <idle>-0 [002] 23454.902249: local_timer_exit: vector=236 <idle>-0 [002] 23454.902250: cpu_idle: state=4294967295 cpu_id=2 <idle>-0 [002] 23454.902251: rcu_utilization: Start context switch <idle>-0 [002] 23454.902252: rcu_utilization: End context switch <idle>-0 [002] 23454.902253: prandom_u32: ret=3692516021 <idle>-0 [002] 23454.902254: sched_switch: swapper/2:0 [120] R ==> cyclictest:12275 [19] <idle>-0 [002] 23454.902256: wakeup_lat: next_comm=cyclictest lat=17 <idle>-0 [002] 23454.902258: kernel_stack: <stack trace > => trace_event_raw_event_synth (ffffffff8121a0db) => action_trace (ffffffff8121e9fb) => event_hist_trigger (ffffffff8121ca8d) => event_triggers_call (ffffffff81216c72) [..]
  • 55. Customize latency tracing # trace-cmd extract -s # trace-cmd report --cpu 2 | tail -30 <idle>-0 [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1 <idle>-0 [002] 23454.902239: sched_wakeup: cyclictest:12275 [19] CPU:002 <idle>-0 [002] 23454.902241: hrtimer_expire_exit: hrtimer=0xffffbbd68286fe60 <idle>-0 [002] 23454.902241: hrtimer_cancel: hrtimer=0xffffbbd6826efe70 <idle>-0 [002] 23454.902242: hrtimer_expire_entry: hrtimer=0xffffbbd6826efe70 <idle>-0 [002] 23454.902243: sched_waking: comm=cyclictest pid=12272 prio=120 target_cpu=002 <idle>-0 [002] 23454.902244: prandom_u32: ret=1102749734 <idle>-0 [002] 23454.902246: sched_wakeup: cyclictest:12272 [120] CPU:002 <idle>-0 [002] 23454.902247: hrtimer_expire_exit: hrtimer=0xffffbbd6826efe70 <idle>-0 [002] 23454.902248: write_msr: 6e0, value 4866ce957272 <idle>-0 [002] 23454.902249: local_timer_exit: vector=236 <idle>-0 [002] 23454.902250: cpu_idle: state=4294967295 cpu_id=2 <idle>-0 [002] 23454.902251: rcu_utilization: Start context switch <idle>-0 [002] 23454.902252: rcu_utilization: End context switch <idle>-0 [002] 23454.902253: prandom_u32: ret=3692516021 <idle>-0 [002] 23454.902254: sched_switch: swapper/2:0 [120] R ==> cyclictest:12275 [19] <idle>-0 [002] 23454.902256: wakeup_lat: next_comm=cyclictest lat=17 <idle>-0 [002] 23454.902258: kernel_stack: <stack trace > => trace_event_raw_event_synth (ffffffff8121a0db) => action_trace (ffffffff8121e9fb) => event_hist_trigger (ffffffff8121ca8d) => event_triggers_call (ffffffff81216c72) [..]
  • 56. Customize latency tracing # trace-cmd extract -s # trace-cmd report --cpu 2 | tail -30 <idle>-0 [001] d..1 23454.902254: cpu_idle: state=0 cpu_id=1 <idle>-0 [002] 23454.902239: sched_wakeup: cyclictest:12275 [19] CPU:002 <idle>-0 [002] 23454.902241: hrtimer_expire_exit: hrtimer=0xffffbbd68286fe60 <idle>-0 [002] 23454.902241: hrtimer_cancel: hrtimer=0xffffbbd6826efe70 <idle>-0 [002] 23454.902242: hrtimer_expire_entry: hrtimer=0xffffbbd6826efe70 <idle>-0 [002] 23454.902243: sched_waking: comm=cyclictest pid=12272 prio=120 target_cpu=002 <idle>-0 [002] 23454.902244: prandom_u32: ret=1102749734 <idle>-0 [002] 23454.902246: sched_wakeup: cyclictest:12272 [120] CPU:002 <idle>-0 [002] 23454.902247: hrtimer_expire_exit: hrtimer=0xffffbbd6826efe70 <idle>-0 [002] 23454.902248: write_msr: 6e0, value 4866ce957272 <idle>-0 [002] 23454.902249: local_timer_exit: vector=236 <idle>-0 [002] 23454.902250: cpu_idle: state=4294967295 cpu_id=2 <idle>-0 [002] 23454.902251: rcu_utilization: Start context switch <idle>-0 [002] 23454.902252: rcu_utilization: End context switch <idle>-0 [002] 23454.902253: prandom_u32: ret=3692516021 <idle>-0 [002] 23454.902254: sched_switch: swapper/2:0 [120] R ==> cyclictest:12275 [19] <idle>-0 [002] 23454.902256: wakeup_lat: next_comm=cyclictest lat=17 <idle>-0 [002] 23454.902258: kernel_stack: <stack trace > => trace_event_raw_event_synth (ffffffff8121a0db) => action_trace (ffffffff8121e9fb) => event_hist_trigger (ffffffff8121ca8d) => event_triggers_call (ffffffff81216c72) [..]
  • 57. Brought to you by Steven Rostedt rostedt@goodmis.org @srostedt