The 'live mode' in perf script essentially sends the stdout of the record process to the stdin of the report process through a pipe. This is OK for low-volume events e.g. for 'perf script rwtop', but breaks down at high volume: root@crownbay:~# perf script sctop syscall events: event count ---------------------------------------- ---------- 3 88768 240 1208 4 127 54 51 265 18 168 18 102 18 142 14 192 12 104 12 91 12 78 12 13 10 146 6 43 4 195 2 197 1 ^CWarning: Processed 589913 events and lost 179 chunks! Check IO/CPU overload! There also seems to be some kind of drawing problem with the display for this script as you can see it visibly drawing line by line.
As a start to this, I've sent out a patchset to lkml that fixes various related problems: http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg370505.html In a lot of cases the high loads are a result of tracing perf-related activity, so I also experimented with the event filters to screen out perf-originated events. e.g. to screen out perf write events: [root@empanada ~]# export x=`expr \`ls /proc/self/task\` + 1`;perf record -a -e syscalls:sys_enter_read -e syscalls:sys_exit_read -e syscalls:sys_enter_write --filter "common_pid != $x" -e syscalls:sys_exit_write --filter "common_pid != $x This works but is pretty unwieldy - need to try to come up with an easier interface that still uses the kernel event filtering engine.
This bug is tracking an enhancement to perf which does not fall under the YP umbrella.