iovisor / iovisor/bcc

CPU timestamp

Open
#976 3 comments 0 reactions 0 assignees View on GitHub
Dominant language
C
Stars
22.7k
Forks
4.1k
Avg merge
10d 4h
Merged PRs (30d)
3

Description

```
# time cksum /usr/bin/* > /dev/null
cksum: /usr/bin/X11: Is a directory

real 0m8.422s
user 0m1.292s
sys 0m0.168s
```

Right now in bcc we have bpf_ktime_get_ns(), which is giving us that "real" time. But what about user and sys time? Or just combine them and call it CPU time? I'm imagining something that fetches it using bpf_get_current_task(), and then reads task->utime, task->stime, etc. If those timestamps aren't updated live, then we'll have to figure out how to fix that too.

Imagine tools like this:

```
# ./funclatency.py -u vfs_read
Tracing 1 functions for "vfs_read"... Hit Ctrl-C to end.
^C
usecs : count distribution
0 -> 1 : 268 |***** |
2 -> 3 : 86 |* |
4 -> 7 : 190 |**** |
8 -> 15 : 1864 |****************************************|
16 -> 31 : 42 | |
32 -> 63 : 17 | |
64 -> 127 : 0 | |
128 -> 255 : 2 | |
256 -> 511 : 2 | |
512 -> 1023 : 14 | |
1024 -> 2047 : 163 |*** |
2048 -> 4095 : 7 | |
4096 -> 8191 : 12 | |
8192 -> 16383 : 20 | |
16384 -> 32767 : 15 | |
32768 -> 65535 : 9 | |
65536 -> 131071 : 7 | |
131072 -> 262143 : 3 | |
262144 -> 524287 : 3 | |
Detaching...
```

And having an option to switch to CPU time only, not elapsed time. And/or an option that printed a histogram for each timestamp type. You can then quickly identify why a function is taking a long time (eg, has outliers): is it because they are on-CPU a lot, or off-CPU?

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.