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:37 UTC|newest]
Thread overview: 17+ 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 ` [PATCH 1/5] mm, shmem: Add shmem resident memory accounting Jerome Marchand
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-08-01 5:01 ` Hugh Dickins
2014-07-22 13:43 ` [PATCH 3/5] mm, shmem: Add shmem_vma() helper Jerome Marchand
2014-07-24 19:53 ` Oleg Nesterov
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-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-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
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 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).