5 ms·

Understanding Linux CPU stats

33 points by itsderek23 12y ago

etep 12y ago
I would like to see stats beyond those provided by top. For example, memory bandwidth (broken into read and write bandwidth). IO bandwidth. CPU cache hit rates. Instructions per cycle. Energy consumption. AFAIK there is no really nice way to see all the true under the hood perf stats. Yes I know about perf, LIKWID, and other similar tools -- point being, I think there is an opportunity to put this kind of monitoring into a tool at the level of scout and truly have something informative.
- suprjami 12y ago
  You should look into PCP. If it's exposed to userspace, you can log it. You can then replay it or graph it, changing the granularity from the sample period upwards.
- bnegreve 12y ago
  You can check perf tool. E.g. $> perf stat echo "hi" Performance counter stats for 'echo hi': 0.718209 task-clock (msec) # 0.595 CPUs utilized 2 context-switches # 0.003 M/sec 0 cpu-migrations # 0.000 K/sec 59 page-faults # 0.082 M/sec 844,067 cycles # 1.175 GHz 561,879 stalled-cycles-frontend # 66.57% frontend cycles idle <not supported> stalled-cycles-backend 611,918 instructions # 0.72 insns per cycle # 0.92 stalled cycles per insn 127,740 branches # 177.859 M/sec 7,279 branch-misses # 5.70% of all branches 0.001207821 seconds time elapsed For more stats, check perf list
glhaynes 12y ago
Where is time spent transitioning from userspace to kernel and back accounted for? And (perhaps relatedly), when does the accounting happen? After each timeslice?
nerdcity 12y ago
Why not describe each element in the actual order that top actually presents them, from left to right, instead of jumping around? #flow
- kagamine 12y ago
  Flow is nice, but the article does explain in the paragraph for id that us & id should be close to 100% when added. That's why they are placed together in the article.
pmontra 12y ago
I confirm that a high waiting time can be due to a damaged disk. I had a server that became slower over the time notwithstanding a constant number of requests. It took me a while to notice a 90% waiting time in top. A disk was dying, I got it replaced and the server got speedy again.

33 points by itsderek23 12y ago

etep 12y ago

I would like to see stats beyond those provided by top. For example, memory bandwidth (broken into read and write bandwidth). IO bandwidth. CPU cache hit rates. Instructions per cycle. Energy consumption. AFAIK there is no really nice way to see all the true under the hood perf stats. Yes I know about perf, LIKWID, and other similar tools -- point being, I think there is an opportunity to put this kind of monitoring into a tool at the level of scout and truly have something informative.

suprjami 12y ago
You should look into PCP. If it's exposed to userspace, you can log it. You can then replay it or graph it, changing the granularity from the sample period upwards.
bnegreve 12y ago
You can check perf tool. E.g. $> perf stat echo "hi" Performance counter stats for 'echo hi': 0.718209 task-clock (msec) # 0.595 CPUs utilized 2 context-switches # 0.003 M/sec 0 cpu-migrations # 0.000 K/sec 59 page-faults # 0.082 M/sec 844,067 cycles # 1.175 GHz 561,879 stalled-cycles-frontend # 66.57% frontend cycles idle <not supported> stalled-cycles-backend 611,918 instructions # 0.72 insns per cycle # 0.92 stalled cycles per insn 127,740 branches # 177.859 M/sec 7,279 branch-misses # 5.70% of all branches 0.001207821 seconds time elapsed For more stats, check perf list

glhaynes 12y ago

Where is time spent transitioning from userspace to kernel and back accounted for? And (perhaps relatedly), when does the accounting happen? After each timeslice?

nerdcity 12y ago

Why not describe each element in the actual order that top actually presents them, from left to right, instead of jumping around? #flow

kagamine 12y ago
Flow is nice, but the article does explain in the paragraph for id that us & id should be close to 100% when added. That's why they are placed together in the article.

pmontra 12y ago

I confirm that a high waiting time can be due to a damaged disk. I had a server that became slower over the time notwithstanding a constant number of requests. It took me a while to notice a 90% waiting time in top. A disk was dying, I got it replaced and the server got speedy again.