On Mon, Sep 12, 2016 at 5:02 AM, Michal Hocko <mhocko@xxxxxxxxxx> wrote: > On Mon 05-09-16 16:14:06, robert.foss@xxxxxxxxxxxxx wrote: >> From: Robert Foss <robert.foss@xxxxxxxxxxxxx> >> >> This series provides the /proc/PID/totmaps feature, which >> summarizes the information provided by /proc/PID/smaps for >> improved performance and usability reasons. >> >> A 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. > > I still maintain my concerns about a single pss value. It might work in > a very specific situations where the consumer knows what is shared but > other than that the value can be more misleading than helpful. So a NACK > from me until I am shown that this is usable in general and still > helpful. I know you think Pss isn't useful in general (though I'll point out two other independent people said they found it useful) but how about the other fields like Swap, Private_Dirty and Private_Shared? If we removed Pss would you still NACK it? > > -- > Michal Hocko > SUSE Labs -- 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
