Groups > linux.kernel > #1720419

Re: [PATCH RFC v2] Add /proc/pid/smaps_rollup

From	Andrew Morton <akpm@linux-foundation.org>
Newsgroups	linux.kernel
Subject	Re: [PATCH RFC v2] Add /proc/pid/smaps_rollup
Date	2017-08-25 23:20 +0200
Message-ID	<uiubg-L8-13@gated-at.bofh.it> (permalink)
References	(4 earlier) <ucSSZ-4jM-7@gated-at.bofh.it> <ucTm2-4w9-21@gated-at.bofh.it> <ud0Qx-1eH-11@gated-at.bofh.it> <ud19U-1Bl-11@gated-at.bofh.it> <uhW9z-4bT-7@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On Thu, 24 Aug 2017 10:55:53 +0200 Michal Hocko <mhocko@kernel.org> wrote:

> > If we assume that the number of VMAs is going to increase over time,
> > then doing anything we can do to reduce the overhead of each VMA
> > during PSS collection seems like the right way to go, and that means
> > outputting an aggregate statistic (to avoid whatever overhead there is
> > per line in writing smaps and in reading each line from userspace).
> > 
> > Also, Dan sent me some numbers from his benchmark measuring PSS on
> > system_server (the big Android process) using smaps vs smaps_rollup:
> > 
> > using smaps:
> > iterations:1000 pid:1163 pss:220023808
> >  0m29.46s real 0m08.28s user 0m20.98s system
> > 
> > using smaps_rollup:
> > iterations:1000 pid:1163 pss:220702720
> >  0m04.39s real 0m00.03s user 0m04.31s system
> 
> I would assume we would do all we can to reduce this kernel->user
> overhead first before considering a new user visible file. I haven't
> seen any attempts except from the low hanging fruid I have tried.

It's hard to believe that we'll get anything like a 5x speedup via
optimization of the existing code?

Thread

Re: [PATCH RFC v2] Add /proc/pid/smaps_rollup Michal Hocko <mhocko@kernel.org> - 2017-08-24 11:00 +0200
  Re: [PATCH RFC v2] Add /proc/pid/smaps_rollup Andrew Morton <akpm@linux-foundation.org> - 2017-08-25 23:20 +0200
    Re: [PATCH RFC v2] Add /proc/pid/smaps_rollup Michal Hocko <mhocko@kernel.org> - 2017-08-28 13:40 +0200

csiph-web