On 2016-08-15 09:42 AM, Michal Hocko wrote:
On Mon 15-08-16 09:00:04, Robert Foss wrote:
On 2016-08-14 05:04 AM, Michal Hocko wrote:
On Fri 12-08-16 18:04:19, robert.foss@xxxxxxxxxxxxx wrote:
From: Robert Foss <robert.foss@xxxxxxxxxxxxx>
This series implements /proc/PID/totmaps, a tool for retrieving summarized
information about the mappings of a process.
The changelog is absolutely missing the usecase. Why do we need this?
Why existing interfaces are not sufficient?
You are absolutely right, more info information is in 1/3.
Patch 1 is silent about the use case as well. It is usually recommended
to describe the motivation for the change in the cover letter.
I'll change it for v3.
But the gist of it is that it provides a faster and more convenient way of
accessing the information in /proc/PID/smaps.
I am sorry to insist but this is far from a description I was hoping
for. Why do we need a more convenient API? Please note that this is a
userspace API which we will have to maintain for ever. We have made many
mistakes in the past where exporting some information made sense at the
time while it turned out being a mistake only later on. So let's make
sure we will not fall into the same trap again.
So please make sure you describe the use case, why the current API is
insufficient and why it cannot be tweaked to provide the information you
are looking for.
I'll add a more elaborate description to the v3 cover letter.
In v1, there was a discussion which I think presented the practical
applications rather well:
https://lkml.org/lkml/2016/8/9/628
or the qoute from Sonny Rao pasted below:
> The use case is to speed up monitoring of
> memory consumption in environments where RSS isn't precise.
>
> For example Chrome tends to many processes which have hundreds of VMAs
> with a substantial amount of shared memory, and the error of using
> RSS rather than PSS tends to be very large when looking at overall
> memory consumption. PSS isn't kept as a single number that's exported
> like RSS, so to calculate PSS means having to parse a very large smaps
> file.
>
> This process is slow and has to be repeated for many processes, and we
> found that the just act of doing the parsing was taking up a
> significant amount of CPU time, so this patch is an attempt to make
> that process cheaper.
If a reformatted version of this still isn't adequate or desirable for
the cover-letter, please give me another heads up.
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
