Messages in this thread | | | Date | Thu, 27 Apr 2017 12:49:40 -0400 | From | Steven Rostedt <> | Subject | Re: [trace-cmd Patch RFC] trace-cmd: top: A new interface to detect peak memory |
| |
On Thu, 27 Apr 2017 19:32:43 +0530 Pratyush Anand <panand@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
| |