From: Jerome Marchand <jmarchan@redhat.com>
To: Hugh Dickins <hughd@google.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-s390@vger.kernel.org, linux-doc@vger.kernel.org,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Ingo Molnar <mingo@redhat.com>, Paul Mackerras <paulus@samba.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
linux390@de.ibm.com, Heiko Carstens <heiko.carstens@de.ibm.com>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
Randy Dunlap <rdunlap@infradead.org>
Subject: Re: [PATCH 1/5] mm, shmem: Add shmem resident memory accounting
Date: Fri, 01 Aug 2014 16:36:52 +0200 [thread overview]
Message-ID: <53DBA604.1090204@redhat.com> (raw)
In-Reply-To: <alpine.LSU.2.11.1407312159180.3912@eggly.anvils>
[-- Attachment #1: Type: text/plain, Size: 4712 bytes --]
On 08/01/2014 07:01 AM, Hugh Dickins wrote:
> On Tue, 22 Jul 2014, Jerome Marchand wrote:
>
>> Currently looking at /proc/<pid>/status or statm, there is no way to
>> distinguish shmem pages from pages mapped to a regular file (shmem
>> pages are mapped to /dev/zero), even though their implication in
>> actual memory use is quite different.
>> This patch adds MM_SHMEMPAGES counter to mm_rss_stat. It keeps track of
>> resident shmem memory size. Its value is exposed in the new VmShm line
>> of /proc/<pid>/status.
>
> I like adding this info to /proc/<pid>/status - thank you -
> but I think you can make the patch much better in a couple of ways.
>
>>
>> Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
>> ---
>> Documentation/filesystems/proc.txt | 2 ++
>> arch/s390/mm/pgtable.c | 2 +-
>> fs/proc/task_mmu.c | 9 ++++++---
>> include/linux/mm.h | 7 +++++++
>> include/linux/mm_types.h | 7 ++++---
>> kernel/events/uprobes.c | 2 +-
>> mm/filemap_xip.c | 2 +-
>> mm/memory.c | 37 +++++++++++++++++++++++++++++++------
>> mm/rmap.c | 8 ++++----
>> 9 files changed, 57 insertions(+), 19 deletions(-)
>>
>> diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
>> index ddc531a..1c49957 100644
>> --- a/Documentation/filesystems/proc.txt
>> +++ b/Documentation/filesystems/proc.txt
>> @@ -171,6 +171,7 @@ read the file /proc/PID/status:
>> VmLib: 1412 kB
>> VmPTE: 20 kb
>> VmSwap: 0 kB
>> + VmShm: 0 kB
>> Threads: 1
>> SigQ: 0/28578
>> SigPnd: 0000000000000000
>> @@ -228,6 +229,7 @@ Table 1-2: Contents of the status files (as of 2.6.30-rc7)
>> VmLib size of shared library code
>> VmPTE size of page table entries
>> VmSwap size of swap usage (the number of referred swapents)
>> + VmShm size of resident shmem memory
>
> Needs to say that includes mappings of tmpfs, and needs to say that
> it's a subset of VmRSS. Better placed immediately after VmRSS...
>
> ...but now that I look through what's in /proc/<pid>/status, it appears
> that we have to defer to /proc/<pid>/statm to see MM_FILEPAGES (third
> field) and MM_ANONPAGES (subtract third field from second field).
>
> That's not a very friendly interface. If you're going to help by
> exposing MM_SHMPAGES separately, please help even more by exposing
> VmFile and VmAnon here in /proc/<pid>/status too.
>
Good point.
> VmRSS, VmAnon, VmShm, VmFile? I'm not sure what's the best order:
> here I'm thinking that anon comes before file in /proc/meminfo, and
> shm should be halfway between anon and file. You may have another idea.
>
> And of course the VmFile count here should exclude VmShm: I think it
> will work out least confusingly if you account MM_FILEPAGES separately
> from MM_SHMPAGES, but add them together where needed e.g. for statm.
I chose not to change MM_FILEPAGES to avoid to break anything, but it
might indeed look better not to have MM_SHMPAGES included in
MM_FILEPAGES. I'll look into it.
>
>> Threads number of threads
>> SigQ number of signals queued/max. number for queue
>> SigPnd bitmap of pending signals for the thread
>> diff --git a/arch/s390/mm/pgtable.c b/arch/s390/mm/pgtable.c
>> index 37b8241..9fe31b0 100644
>> --- a/arch/s390/mm/pgtable.c
>> +++ b/arch/s390/mm/pgtable.c
>> @@ -612,7 +612,7 @@ static void gmap_zap_swap_entry(swp_entry_t entry, struct mm_struct *mm)
>> if (PageAnon(page))
>> dec_mm_counter(mm, MM_ANONPAGES);
>> else
>> - dec_mm_counter(mm, MM_FILEPAGES);
>> + dec_mm_file_counters(mm, page);
>> }
>
> That is a recurring pattern: please try putting
>
> static inline int mm_counter(struct page *page)
> {
> if (PageAnon(page))
> return MM_ANONPAGES;
> if (PageSwapBacked(page))
> return MM_SHMPAGES;
> return MM_FILEPAGES;
> }
>
> in include/linux/mm.h.
>
> Then dec_mm_counter(mm, mm_counter(page)) here, and wherever you can,
> use mm_counter(page) to simplify the code throughout.
>
> I say "try" because I think factoring out mm_counter() will simplify
> the most code, given the profusion of different accessors, particularly
> in mm/memory.c. But I'm not sure how much bloat having it as an inline
> function will add, versus how much overhead it would add if not inline.
I'll look into that.
Jerome
>
> Hugh
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 538 bytes --]
next prev parent reply other threads:[~2014-08-01 14:36 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-22 13:43 [PATCH RESEND 0/5] mm, shmem: Enhance per-process accounting of shared memory Jerome Marchand
2014-07-22 13:43 ` Jerome Marchand
2014-07-22 13:43 ` [PATCH 1/5] mm, shmem: Add shmem resident memory accounting Jerome Marchand
2014-07-22 13:43 ` Jerome Marchand
2014-08-01 5:01 ` Hugh Dickins
2014-08-01 5:01 ` Hugh Dickins
2014-08-01 14:36 ` Jerome Marchand [this message]
2014-07-22 13:43 ` [PATCH 2/5] mm, shmem: Add shmem_locate function Jerome Marchand
2014-07-22 13:43 ` Jerome Marchand
2014-08-01 5:01 ` Hugh Dickins
2014-08-01 5:01 ` Hugh Dickins
2014-07-22 13:43 ` [PATCH 3/5] mm, shmem: Add shmem_vma() helper Jerome Marchand
2014-07-22 13:43 ` Jerome Marchand
2014-07-24 19:53 ` Oleg Nesterov
2014-07-24 19:53 ` Oleg Nesterov
2014-08-01 5:03 ` Hugh Dickins
2014-08-01 5:03 ` Hugh Dickins
2014-08-01 14:37 ` Jerome Marchand
2014-07-22 13:43 ` [PATCH 4/5] mm, shmem: Add shmem swap memory accounting Jerome Marchand
2014-07-22 13:43 ` Jerome Marchand
2014-08-01 5:05 ` Hugh Dickins
2014-08-01 5:05 ` Hugh Dickins
2014-08-01 14:44 ` Jerome Marchand
2014-07-22 13:43 ` [PATCH 5/5] mm, shmem: Show location of non-resident shmem pages in smaps Jerome Marchand
2014-07-22 13:43 ` Jerome Marchand
2014-08-01 5:06 ` Hugh Dickins
2014-08-01 5:06 ` Hugh Dickins
2014-08-01 15:23 ` Jerome Marchand
-- strict thread matches above, loose matches on Subject: below --
2014-07-01 13:01 [PATCH 0/5] mm, shmem: Enhance per-process accounting of shared memnory Jerome Marchand
2014-07-01 13:01 ` [PATCH 1/5] mm, shmem: Add shmem resident memory accounting Jerome Marchand
2014-07-01 13:01 ` Jerome Marchand
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=53DBA604.1090204@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=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 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.