From: Minchan Kim <minchan@kernel.org>
To: Daniel Colascione <dancol@google.com>,
Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, timmurray@google.com,
joelaf@google.com, viro@zeniv.linux.org.uk,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
Michal Hocko <mhocko@suse.com>,
sonnyrao@chromium.org, robert.foss@collabora.com
Subject: Re: [PATCH RFC v2] Add /proc/pid/smaps_rollup
Date: Thu, 10 Aug 2017 13:38:31 +0900 [thread overview]
Message-ID: <20170810043831.GB2249@bbox> (raw)
In-Reply-To: <20170810001557.147285-1-dancol@google.com>
On Wed, Aug 09, 2017 at 05:15:57PM -0700, Daniel Colascione wrote:
> /proc/pid/smaps_rollup is a new proc file that improves the
> performance of user programs that determine aggregate memory
> statistics (e.g., total PSS) of a process.
>
> Android regularly "samples" the memory usage of various processes in
> order to balance its memory pool sizes. This sampling process involves
> opening /proc/pid/smaps and summing certain fields. For very large
> processes, sampling memory use this way can take several hundred
> milliseconds, due mostly to the overhead of the seq_printf calls in
> task_mmu.c.
>
> smaps_rollup improves the situation. It contains most of the fields of
> /proc/pid/smaps, but instead of a set of fields for each VMA,
> smaps_rollup instead contains one synthetic smaps-format entry
> representing the whole process. In the single smaps_rollup synthetic
> entry, each field is the summation of the corresponding field in all
> of the real-smaps VMAs. Using a common format for smaps_rollup and
> smaps allows userspace parsers to repurpose parsers meant for use with
> non-rollup smaps for smaps_rollup, and it allows userspace to switch
> between smaps_rollup and smaps at runtime (say, based on the
> availability of smaps_rollup in a given kernel) with minimal fuss.
>
> By using smaps_rollup instead of smaps, a caller can avoid the
> significant overhead of formatting, reading, and parsing each of a
> large process's potentially very numerous memory mappings. For
> sampling system_server's PSS in Android, we measured a 12x speedup,
> representing a savings of several hundred milliseconds.
>
> One alternative to a new per-process proc file would have been
> including PSS information in /proc/pid/status. We considered this
> option but thought that PSS would be too expensive (by a few orders of
> magnitude) to collect relative to what's already emitted as part of
> /proc/pid/status, and slowing every user of /proc/pid/status for the
> sake of readers that happen to want PSS feels wrong.
>
> The code itself works by reusing the existing VMA-walking framework we
> use for regular smaps generation and keeping the mem_size_stats
> structure around between VMA walks instead of using a fresh one for
> each VMA. In this way, summation happens automatically. We let
> seq_file walk over the VMAs just as it does for regular smaps and just
> emit nothing to the seq_file until we hit the last VMA.
>
> Patch changelog:
>
> v2: Fix typo in commit message
> Add ABI documentation as requested by gregkh
>
> Signed-off-by: Daniel Colascione <dancol@google.com>
I love this.
FYI, there was trial but got failed at that time so in this time,
https://marc.info/?l=linux-kernel&m=147310650003277&w=2
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1229163.html
I really hope we merge this patch.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Minchan Kim <minchan@kernel.org>
To: Daniel Colascione <dancol@google.com>,
Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, timmurray@google.com,
joelaf@google.com, viro@zeniv.linux.org.uk,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
Michal Hocko <mhocko@suse.com>,
sonnyrao@chromium.org, robert.foss@collabora.com
Subject: Re: [PATCH RFC v2] Add /proc/pid/smaps_rollup
Date: Thu, 10 Aug 2017 13:38:31 +0900 [thread overview]
Message-ID: <20170810043831.GB2249@bbox> (raw)
In-Reply-To: <20170810001557.147285-1-dancol@google.com>
On Wed, Aug 09, 2017 at 05:15:57PM -0700, Daniel Colascione wrote:
> /proc/pid/smaps_rollup is a new proc file that improves the
> performance of user programs that determine aggregate memory
> statistics (e.g., total PSS) of a process.
>
> Android regularly "samples" the memory usage of various processes in
> order to balance its memory pool sizes. This sampling process involves
> opening /proc/pid/smaps and summing certain fields. For very large
> processes, sampling memory use this way can take several hundred
> milliseconds, due mostly to the overhead of the seq_printf calls in
> task_mmu.c.
>
> smaps_rollup improves the situation. It contains most of the fields of
> /proc/pid/smaps, but instead of a set of fields for each VMA,
> smaps_rollup instead contains one synthetic smaps-format entry
> representing the whole process. In the single smaps_rollup synthetic
> entry, each field is the summation of the corresponding field in all
> of the real-smaps VMAs. Using a common format for smaps_rollup and
> smaps allows userspace parsers to repurpose parsers meant for use with
> non-rollup smaps for smaps_rollup, and it allows userspace to switch
> between smaps_rollup and smaps at runtime (say, based on the
> availability of smaps_rollup in a given kernel) with minimal fuss.
>
> By using smaps_rollup instead of smaps, a caller can avoid the
> significant overhead of formatting, reading, and parsing each of a
> large process's potentially very numerous memory mappings. For
> sampling system_server's PSS in Android, we measured a 12x speedup,
> representing a savings of several hundred milliseconds.
>
> One alternative to a new per-process proc file would have been
> including PSS information in /proc/pid/status. We considered this
> option but thought that PSS would be too expensive (by a few orders of
> magnitude) to collect relative to what's already emitted as part of
> /proc/pid/status, and slowing every user of /proc/pid/status for the
> sake of readers that happen to want PSS feels wrong.
>
> The code itself works by reusing the existing VMA-walking framework we
> use for regular smaps generation and keeping the mem_size_stats
> structure around between VMA walks instead of using a fresh one for
> each VMA. In this way, summation happens automatically. We let
> seq_file walk over the VMAs just as it does for regular smaps and just
> emit nothing to the seq_file until we hit the last VMA.
>
> Patch changelog:
>
> v2: Fix typo in commit message
> Add ABI documentation as requested by gregkh
>
> Signed-off-by: Daniel Colascione <dancol@google.com>
I love this.
FYI, there was trial but got failed at that time so in this time,
https://marc.info/?l=linux-kernel&m=147310650003277&w=2
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1229163.html
I really hope we merge this patch.
next prev parent reply other threads:[~2017-08-10 4:38 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-08 13:25 [PATCH] Add /proc/pid/smaps_rollup Daniel Colascione
2017-08-08 18:22 ` Daniel Colascione
2017-08-08 18:42 ` Greg KH
2017-08-08 18:51 ` Daniel Colascione
2017-08-08 18:56 ` Greg KH
2017-08-10 0:15 ` [PATCH RFC v2] " Daniel Colascione
2017-08-10 0:15 ` Daniel Colascione
2017-08-10 1:24 ` Randy Dunlap
2017-08-10 1:24 ` Randy Dunlap
2017-08-10 1:33 ` Daniel Colascione
2017-08-10 4:38 ` Minchan Kim [this message]
2017-08-10 4:38 ` Minchan Kim
2017-08-10 8:46 ` Michal Hocko
2017-08-10 8:46 ` Michal Hocko
2017-08-10 10:23 ` Daniel Colascione
2017-08-10 10:23 ` Daniel Colascione
2017-08-10 10:58 ` Michal Hocko
2017-08-10 10:58 ` Michal Hocko
[not found] ` <20170810105852.GM23863-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2017-08-10 18:56 ` Sonny Rao
2017-08-10 18:56 ` Sonny Rao
2017-08-10 18:56 ` Sonny Rao
2017-08-10 19:17 ` Tim Murray
2017-08-10 19:17 ` Tim Murray
2017-08-24 8:55 ` Michal Hocko
2017-08-24 8:55 ` Michal Hocko
[not found] ` <20170824085553.GB5943-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2017-08-25 21:16 ` Andrew Morton
2017-08-25 21:16 ` Andrew Morton
2017-08-25 21:16 ` Andrew Morton
[not found] ` <20170825141637.f11a36a9997b4b705d5b6481-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2017-08-28 11:30 ` Michal Hocko
2017-08-28 11:30 ` Michal Hocko
2017-08-28 11:30 ` Michal Hocko
2017-08-12 2:21 ` [PATCH v3] " Daniel Colascione
2017-08-12 2:21 ` Daniel Colascione
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170810043831.GB2249@bbox \
--to=minchan@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=dancol@google.com \
--cc=joelaf@google.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=robert.foss@collabora.com \
--cc=sonnyrao@chromium.org \
--cc=timmurray@google.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.