CPU timestamp
- 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.