All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Jerome Marchand <jmarchan@redhat.com>
Cc: linux-mm@kvack.org, 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
Subject: Re: [RFC PATCH v2 5/5] mm, shmem: Show location of non-resident shmem pages in smaps
Date: Mon, 15 Sep 2014 19:29:24 +0200	[thread overview]
Message-ID: <20140915172923.GA26275@redhat.com> (raw)
In-Reply-To: <54171829.3090108@redhat.com>

On 09/15, Jerome Marchand wrote:
>
> On 09/15/2014 06:21 PM, Oleg Nesterov wrote:
> > Hi Jerome,
> >
> > Not sure I understand this patch correctly, will try to read it later.
> > But a couple of nits/questions anyway,
> >
> > On 09/15, Jerome Marchand wrote:
> >>
> >> +The ShmXXX lines only appears for shmem mapping. They show the amount of memory
> >> +from the mapping that is currently:
> >> + - resident in RAM but not mapped into any process (ShmNotMapped)
> >
> > But how can we know that it is not mapped by another process?
>
> Its mapcount is zero.

Ah, yes, I missed the "!count" check. Thanks!

> > And in fact "not mapped" looks confusing (at least to me).
>
> "Not mapped" as "not present in a page table". It does belong to a
> userspace mapping though. I wonder if there is a less ambiguous terminology.

To me "not present in page tables" looks more understandable, but I won't
insist.

> > IIUC it is actually
> > mapped even by this process, just it never tried to fault these (resident or
> > swapped) pages in. Right?
>
> No these pages are in the page cache. This can happen when the only
> process which have accessed these exits or munmap() the mapping.

Yes, yes, I meant that this process didn't touch these pages and thus
pte_none() == T.

> > And I am not sure why we ignore SHMEM_SWAPCACHE...
>
> Hugh didn't like it as it is a small and transient value.

OK, but perhaps update_shmem_stats() should treat it as SHMEM_SWAP.
Nevermind, I leave this to you and Hugh.

Oleg.

--
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: Oleg Nesterov <oleg@redhat.com>
To: Jerome Marchand <jmarchan@redhat.com>
Cc: linux-mm@kvack.org, 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
Subject: Re: [RFC PATCH v2 5/5] mm, shmem: Show location of non-resident shmem pages in smaps
Date: Mon, 15 Sep 2014 19:29:24 +0200	[thread overview]
Message-ID: <20140915172923.GA26275@redhat.com> (raw)
In-Reply-To: <54171829.3090108@redhat.com>

On 09/15, Jerome Marchand wrote:
>
> On 09/15/2014 06:21 PM, Oleg Nesterov wrote:
> > Hi Jerome,
> >
> > Not sure I understand this patch correctly, will try to read it later.
> > But a couple of nits/questions anyway,
> >
> > On 09/15, Jerome Marchand wrote:
> >>
> >> +The ShmXXX lines only appears for shmem mapping. They show the amount of memory
> >> +from the mapping that is currently:
> >> + - resident in RAM but not mapped into any process (ShmNotMapped)
> >
> > But how can we know that it is not mapped by another process?
>
> Its mapcount is zero.

Ah, yes, I missed the "!count" check. Thanks!

> > And in fact "not mapped" looks confusing (at least to me).
>
> "Not mapped" as "not present in a page table". It does belong to a
> userspace mapping though. I wonder if there is a less ambiguous terminology.

To me "not present in page tables" looks more understandable, but I won't
insist.

> > IIUC it is actually
> > mapped even by this process, just it never tried to fault these (resident or
> > swapped) pages in. Right?
>
> No these pages are in the page cache. This can happen when the only
> process which have accessed these exits or munmap() the mapping.

Yes, yes, I meant that this process didn't touch these pages and thus
pte_none() == T.

> > And I am not sure why we ignore SHMEM_SWAPCACHE...
>
> Hugh didn't like it as it is a small and transient value.

OK, but perhaps update_shmem_stats() should treat it as SHMEM_SWAP.
Nevermind, I leave this to you and Hugh.

Oleg.


  reply	other threads:[~2014-09-15 17:29 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-15 14:24 [RFC PATCH v2 0/5] mm, shmem: Enhance per-process accounting of shared memory Jerome Marchand
2014-09-15 14:24 ` Jerome Marchand
2014-09-15 14:24 ` [RFC PATCH v2 1/5] mm, shmem: Add shmem resident memory accounting Jerome Marchand
2014-09-15 14:24   ` 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   ` 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   ` 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   ` 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 14:24   ` Jerome Marchand
2014-09-15 16:21   ` Oleg Nesterov
2014-09-15 16:21     ` Oleg Nesterov
2014-09-15 16:47     ` Jerome Marchand
2014-09-15 17:29       ` Oleg Nesterov [this message]
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=20140915172923.GA26275@redhat.com \
    --to=oleg@redhat.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@kernel.org \
    --cc=heiko.carstens@de.ibm.com \
    --cc=hughd@google.com \
    --cc=jmarchan@redhat.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.