On Thu, 27 Apr 2017 19:32:43 +0530 Pratyush Anand <pan...@redhat.com> wrote:
> I will implement your review comments and will send next revision. > However, I had couple of observation which I was unable to justify: > > # ./trace-cmd top -s /tmp/test > # ./trace-cmd top -p /tmp/test | grep trace-cmd > 15292 trace-cmd 22144 15808 What does it give for your /tmp/test ? Note, tracing doesn't start till after trace-cmd is loaded. Everything before is not going to be seen. > Here,15292 is the pid of trace-cmd task > 22144 KB is the peak memory usage > 15808 KB is the current memory usage > > Now check rss component from statm > # cat /proc/15292/statm > 50 35 23 7 0 12 0 36 > > This is a result on ARM64/64KB page size. Therefore, as per statm rss is 35 > pages = 35*64 = 2240KB > I patched my kernel [2] for test purpose, so that statm reports peak memory > as > well. Here, the last extra entry in statm output is peak memory and it is 36 > pages = 2304KB. > So, this is a huge difference between what has been reported by statm and > what > we get from trace-cmd. > I understand that `trace-cmd top` output would only be approximate, because > many of the memory could be allocated by task and freed in interrupt context. > So, many a time it can differ. But, is such a huge difference justified? If > yes, can we count on the output of this utility to find early boot time oom > issues? Doesn't it only just trace the memory usage of when the tracing starts? -- Steve > > > [1] > https://github.com/pratyushanand/trace-cmd/commit/602c2cd96aa613633ad20c6d382e41f7db37a2a4 > [2] > https://github.com/pratyushanand/linux/commit/197e2045361b6b70085c46c78ea6607d8afce517
