linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Jerome Marchand" <jmarchan@redhat.com>
To: linux-mm@kvack.org
Cc: Randy Dunlap <rdunlap@infradead.org>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	linux390@de.ibm.com, Hugh Dickins <hughd@google.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Paul Mackerras <paulus@samba.org>, Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-s390@vger.kernel.org, Oleg Nesterov <oleg@redhat.com>
Subject: [RFC PATCH v2 0/5] mm, shmem: Enhance per-process accounting of shared memory
Date: Mon, 15 Sep 2014 16:24:32 +0200	[thread overview]
Message-ID: <1410791077-5300-1-git-send-email-jmarchan@redhat.com> (raw)

Changes since v1:
 - Add VmFile and VmAnon line to /proc/<pid>/status.
 - Split first patch: new accounting code on one side and and adding
 new fields to status on the other.
 - Remove ShmOther and ShmSwapCache from smaps and rename ShmOrphan to
 ShmNotMapped.
 - Drop fourth patch "mm, shmem: Add shmem swap memory accounting".
 - Minor implementation details.

I also tried again to come to a better way to account for shmem swap
pages, but my effort were again unsuccessful. Any suggestion is gladly
welcome.

There are several shortcomings with the accounting of shared memory
(sysV shm, shared anonymous mapping, mapping to a tmpfs file). The
values in /proc/<pid>/status and statm don't allow to distinguish
between shmem memory and a shared mapping to a regular file, even
though theirs implication on memory usage are quite different: at
reclaim, file mapping can be dropped or write back on disk while shmem
needs a place in swap. As for shmem pages that are swapped-out or in
swap cache, they aren't accounted at all.

This series addresses these issues by adding new fields to status and
smaps file in /proc/<pid>/. The accounting of resident shared memory is
made in the same way as it's currently done for resident memory and
general swap (a counter in mm_rss_stat), but this approach proved
impractical for paged-out shared memory (it would requires a rmap walk
each time a page is paged-in).

/proc/<pid>/smaps also lacks proper accounting of shared memory since
shmem subsystem hides all implementation detail to generic mm code.
This series adds the shmem_locate() function that returns the location
of a particular page (resident, in swap or swap cache). Called from
smaps code, it allows to show more detailled accounting of shmem
mappings in smaps.

Patch 1 adds a counter to keep track of resident shmem memory.
Patch 2 adds VmFile, VmAnon and VmShm lines to /proc/<pid>/status.
Patch 3 adds a function to allow generic code to know the physical
location of a shmem page.
Patch 4 adds simple helper function.
Patch 5 adds shmem specific fields to /proc/<pid>/smaps.

Thanks,
Jerome

Jerome Marchand (5):
  mm, shmem: Add shmem resident memory accounting
  mm, procfs: Display VmAnon, VmFile and VmShm in /proc/pid/status
  mm, shmem: Add shmem_locate function
  mm, shmem: Add shmem_vma() helper
  mm, shmem: Show location of non-resident shmem pages in smaps

 Documentation/filesystems/proc.txt | 16 +++++++++-
 arch/s390/mm/pgtable.c             |  5 +---
 fs/proc/task_mmu.c                 | 60 ++++++++++++++++++++++++++++++++++++--
 include/linux/mm.h                 | 10 +++++++
 include/linux/mm_types.h           |  7 +++--
 include/linux/shmem_fs.h           |  7 +++++
 kernel/events/uprobes.c            |  2 +-
 mm/filemap_xip.c                   |  2 +-
 mm/memory.c                        | 28 +++++-------------
 mm/oom_kill.c                      |  5 ++--
 mm/rmap.c                          | 17 ++++-------
 mm/shmem.c                         | 35 ++++++++++++++++++++++
 12 files changed, 147 insertions(+), 47 deletions(-)

-- 
1.9.3

--
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>

             reply	other threads:[~2014-09-15 14:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-15 14:24 Jerome Marchand [this message]
2014-09-15 14:24 ` [RFC PATCH v2 1/5] mm, shmem: Add shmem resident memory accounting Jerome Marchand
2014-09-15 14:24 ` [RFC PATCH v2 2/5] mm, procfs: Display VmAnon, VmFile and VmShm in /proc/pid/status Jerome Marchand
2014-09-15 14:24 ` [RFC PATCH v2 3/5] mm, shmem: Add shmem_locate function Jerome Marchand
2014-09-15 14:24 ` [RFC PATCH v2 4/5] mm, shmem: Add shmem_vma() helper Jerome Marchand
2014-09-15 14:24 ` [RFC PATCH v2 5/5] mm, shmem: Show location of non-resident shmem pages in smaps Jerome Marchand
2014-09-15 16:21   ` Oleg Nesterov
2014-09-15 16:47     ` Jerome Marchand
2014-09-15 17:29       ` Oleg Nesterov

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=1410791077-5300-1-git-send-email-jmarchan@redhat.com \
    --to=jmarchan@redhat.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@kernel.org \
    --cc=heiko.carstens@de.ibm.com \
    --cc=hughd@google.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux390@de.ibm.com \
    --cc=mingo@redhat.com \
    --cc=oleg@redhat.com \
    --cc=paulus@samba.org \
    --cc=rdunlap@infradead.org \
    --cc=schwidefsky@de.ibm.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).