Re: [trace-cmd Patch RFC] trace-cmd: top: A new interface to detect peak memory

[Steven Rostedt]

On Thu, 27 Apr 2017 19:32:43 +0530
Pratyush Anand <panand@xxxxxxxxxx> 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