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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 27 Apr 2017 12:49:40 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Pratyush Anand <panand@...hat.com>
Cc:     linux-kernel@...r.kernel.org, dyoung@...hat.com, xlpang@...hat.com
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@...hat.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