From: Arjan van de Ven <arjan@infradead.org>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org, "Chen,
Kenneth W" <kenneth.w.chen@intel.com>,
linux-mm@kvack.org, Nick Piggin <npiggin@suse.de>
Subject: Re: RSS accounting (was: Re: 2.6.19-rc1-mm1)
Date: Tue, 10 Oct 2006 18:13:10 +0200 [thread overview]
Message-ID: <1160496790.3000.319.camel@laptopd505.fenrus.org> (raw)
In-Reply-To: <1160486087.25613.52.camel@taijtu>
On Tue, 2006-10-10 at 15:14 +0200, Peter Zijlstra wrote:
> >
> > We need to consider at least if any of the following are part of rss:
> > * VM_IO io mmaped device stuff
> > * Non-linear mappings
> > * Shared hugetlb memory that shares pagetables
> > * Shared hugetlb memory
> > * Hugetlb memory in general
> > * Shared normal memory that shares pagetables
> > * Shared normal memory (file backed; eg pagecache)
> > * Shared normal memory (anonymous/non-file-backed)
> > * Sysv/ipc shared memory
> > * Not shared normal memory
> So we have three cases where RSS matters besides presenting a number to
> user-space;
> - shared page tables
> - containers
> - rlimit
>
> Preferably they will all share a common definition of what RSS is; since
> containers must account shared pages somehow (not doing so would open up
> a large hole to DoS the other containers) and the container case can be
> argued to be an extension of the rlimit case we cannot just ignore them.
>
> As then what to do with them, I've yet to figure out. Some random bit
> floating in my brain;
> - VM_IO can be discarted, its not actual memory
agreed (although I think we do count it today; this is half of what
makes X look so bloated, next to firefox ;)
>
> - hugetlb is memory too, so I'd not special case this (other than the
> different unit of accounting)
agreed again; personally I don't think hugetlb memory should be special;
especially with all the libhugetlbfs work on making it real easy for
apps to use; the more it's used the more people would notice something
funky with it.
> - shared mapped pages could be accounted on vma level, since both
> containers have access to the same file, there is already an imbalance,
> so I'd not worry about the 1%-99% usage scenario here.
or one level below; if you count it in the actual PTE page then the
sharing case will "just work". It's a trick question; do you count it as
100% or do you count it as 100% / number of sharers.
> - regular, non mapped, pagecache pages however have no owner - what to
> do. (fake vma - which would result in each container paying equally for
> all these pages?)
if they're clean I wouldn't count them to anything actually
> Anyway, I'd rather not break RSS twice, once now because we don't quite
> know what to do, and later when we do get an acceptable mm container and
> have to include shared memory in one way or the other.
RSS of a container versus RSS of a process is an interesting question
for sure ;)
next prev parent reply other threads:[~2006-10-10 16:13 UTC|newest]
Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-10 7:09 2.6.19-rc1-mm1 Andrew Morton
2006-10-10 7:20 ` 2.6.19-rc1-mm1 Arjan van de Ven
2006-10-10 7:45 ` 2.6.19-rc1-mm1 Andrew Morton
2006-10-10 8:03 ` 2.6.19-rc1-mm1 Arjan van de Ven
2006-10-10 13:14 ` RSS accounting (was: Re: 2.6.19-rc1-mm1) Peter Zijlstra
2006-10-10 16:13 ` Arjan van de Ven [this message]
2006-10-10 23:54 ` Eric W. Biederman
2006-10-11 8:47 ` Arjan van de Ven
2006-10-11 12:07 ` Eric W. Biederman
2006-10-11 13:55 ` Arjan van de Ven
2006-10-11 17:15 ` Chen, Kenneth W
2006-10-11 22:36 ` Benjamin LaHaise
2006-10-10 7:31 ` 2.6.19-rc1-mm1 Miguel Ojeda
2006-10-10 8:10 ` 2.6.19-rc1-mm1 Andrew Morton
2006-10-10 9:57 ` 2.6.19-rc1-mm1 Miguel Ojeda
2006-10-10 18:25 ` 2.6.19-rc1-mm1 Jeremy Fitzhardinge
2006-10-10 12:19 ` 2.6.19-rc1-mm1 Theodore Tso
2006-10-10 12:26 ` 2.6.19-rc1-mm1 Arjan van de Ven
2006-10-10 16:21 ` 2.6.19-rc1-mm1 Andrew Morton
2006-10-10 13:10 ` 2.6.19-rc1-mm1 Michal Piotrowski
2006-10-10 14:04 ` 2.6.19-rc1-mm1 Michal Piotrowski
2006-10-11 5:35 ` 2.6.19-rc1-mm1 Neil Brown
2006-10-11 10:48 ` 2.6.19-rc1-mm1 Michal Piotrowski
2006-10-11 11:23 ` 2.6.19-rc1-mm1 Arjan van de Ven
2006-10-11 13:08 ` _cpu_down deadlock [was Re: 2.6.19-rc1-mm1] Neil Brown
2006-10-11 13:32 ` Rusty Russell
2006-10-11 16:39 ` Andrew Morton
2006-10-11 23:46 ` Neil Brown
2006-10-12 6:51 ` Arjan van de Ven
2006-10-12 7:53 ` SPAM: " Neil Brown
2006-10-12 8:04 ` Andrew Morton
2006-10-13 4:49 ` Neil Brown
2006-10-10 15:47 ` BUG in filp_close() (was: Re: 2.6.19-rc1-mm1) Dave Kleikamp
2006-10-10 22:07 ` Dave Kleikamp
2006-10-10 22:14 ` Vadim Lobanov
2006-10-10 22:38 ` Vadim Lobanov
2006-10-10 16:09 ` 2.6.19-rc1-mm1 Michal Piotrowski
2006-10-10 19:04 ` 2.6.19-rc1-mm1 Andrew Morton
2006-10-10 21:44 ` 2.6.19-rc1-mm1 Michal Piotrowski
2006-10-10 21:52 ` 2.6.19-rc1-mm1 Andrew Morton
2006-10-20 20:44 ` 2.6.19-rc1-mm1 Thomas Gleixner
2006-10-10 17:15 ` BUG() in copy_fdtable() with 64K pages (2.6.19-rc1-mm1) Olof Johansson
2006-10-10 19:34 ` Andrew Morton
2006-10-10 20:20 ` Linas Vepstas
2006-10-10 20:31 ` Vadim Lobanov
2006-10-10 23:05 ` Linas Vepstas
2006-10-10 18:09 ` 2.6.19-rc1-mm1 Jeremy Fitzhardinge
2006-10-10 19:25 ` 2.6.19-rc1-mm1 Andrew Morton
2006-10-10 19:41 ` 2.6.19-rc1-mm1 Jeremy Fitzhardinge
2006-10-10 23:10 ` 2.6.19-rc1-mm1 Paul Mackerras
2006-10-10 23:16 ` 2.6.19-rc1-mm1 Jeremy Fitzhardinge
2006-10-10 23:37 ` 2.6.19-rc1-mm1 Andrew Morton
2006-10-10 22:17 ` 2.6.19-rc1-mm1 Badari Pulavarty
2006-10-11 6:56 ` 2.6.19-rc1-mm1 Arjan van de Ven
2006-10-11 3:13 ` 2.6.19-rc1-mm1 Badari Pulavarty
2006-10-11 4:01 ` 2.6.19-rc1-mm1 Andrew Morton
[not found] ` <1160578934.1447.1.camel@dyn9047017100.beaverton.ibm.com>
2006-10-11 16:56 ` 2.6.19-rc1-mm1 (ext4 problem ?) Andrew Morton
2006-10-11 17:08 ` Badari Pulavarty
2006-10-11 12:51 ` 2.6.19-rc1-mm1 Theodore Tso
2006-10-11 19:54 ` 2.6.19-rc1-mm1 Martin J. Bligh
2006-10-11 21:58 ` 2.6.19-rc1-mm1 Badari Pulavarty
2006-10-16 15:56 ` 2.6.19-rc1-mm1 Andy Whitcroft
2006-10-11 19:59 ` 2.6.19-rc1-mm1 Martin J. Bligh
2006-10-11 20:10 ` 2.6.19-rc1-mm1 Michal Piotrowski
2006-10-11 21:47 ` 2.6.19-rc1-mm1 Andrew Morton
2006-10-12 10:22 ` 2.6.19-rc1-mm1 Andy Whitcroft
2006-10-12 18:09 ` 2.6.19-rc1-mm1 Badari Pulavarty
2006-10-12 18:52 ` 2.6.19-rc1-mm1 Vadim Lobanov
2006-10-12 19:01 ` 2.6.19-rc1-mm1 Badari Pulavarty
2006-10-11 21:19 ` 2.6.19-rc1-mm1 Michael Lothian
2006-10-12 12:18 ` 2.6.19-rc1-mm1 - locks when using "dd bs=1M" from card reader Helge Hafting
2006-10-12 18:29 ` Andrew Morton
2006-10-13 13:11 ` Helge Hafting
2006-10-13 16:29 ` Andrew Morton
2006-10-13 18:10 ` [linux-usb-devel] " Alan Stern
2006-10-18 9:31 ` Helge Hafting
2006-10-18 16:26 ` Alan Stern
2006-10-19 12:25 ` Helge Hafting
2006-10-19 18:40 ` Alan Stern
2006-10-19 18:57 ` Christopher "Monty" Montgomery
2006-10-20 11:44 ` Helge Hafting
2006-10-20 15:55 ` Alan Stern
2006-10-23 9:12 ` Helge Hafting
2006-10-23 14:13 ` Alan Stern
2006-10-23 20:36 ` Christopher "Monty" Montgomery
2006-10-24 10:16 ` Helge Hafting
2006-10-24 14:09 ` Alan Stern
2006-10-12 18:37 ` 2.6.19-rc1-mm1 Valdis.Kletnieks
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=1160496790.3000.319.camel@laptopd505.fenrus.org \
--to=arjan@infradead.org \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@osdl.org \
--cc=kenneth.w.chen@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=npiggin@suse.de \
/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
all inboxes | Powered by JetHome®