Re: [PATCH v5 0/3] mm, proc: Implement /proc/<pid>/totmaps

On Mon, Sep 19, 2016 at 09:51:13PM +0200, Michal Hocko wrote:

[not sure why the CC list was trimmed - do no do that please unless you
 have a strong reason for that - if this was not intentional please
 restpre it]

Ah, sorry, pressed the wrong key.

On Mon 19-09-16 21:40:01, Jann Horn wrote:

quoted

On Mon, Sep 19, 2016 at 09:32:38PM +0200, Michal Hocko wrote:

quoted

On Mon 19-09-16 11:16:31, Robert Foss wrote:

quoted

On 2016-09-14 05:12 AM, Michal Hocko wrote:

quoted

On Tue 13-09-16 13:27:39, Sonny Rao wrote:

[...]

quoted

quoted

quoted

Given that smaps
doesn't provide this in a straightforward way, what do you think is
the right way to provide this information?

I would be tempted to sneak it into /proc/<pid>/statm because that looks
like a proper place but getting this information is not for free
performance wise so I am not really sure something that relies on this
file would see unexpected stalls. Maybe this could be worked around by
some caching... I would suggest to check who is actually using this file
(top/ps etc...)

What would this caching look like? Can any information be re-used between
vma walks?

yes basically return the same value if called within HZ or something
similar. But that assumes that statm latency really matters and it is
called often enough.

That sounds horrible. If some application decides that they want to check
statm directly after some action or so (like after program startup), this is
going to give them a very bad time. That probably doesn't happen
often - but still.

I can already imagine some developer going "yeah, that usleep()... that's
because the kernel API returns stale information for a couple milliseconds
after we do something *shrug*".

What are you trying to optimize for? Ten users on the same machine, each of
which is running "top" because it looks so great?

Please try to read what I wrote again. I didn't say this would be
needed. The idea was that _if_ /proc/<pid>/statm is used very _often_
than some caching might help to reduce the overhead. Especially when you
consider that the information is not precise anyway. It can change
anytime while you are doing the address space walk.