From: Arjan van de Ven <arjan@infradead.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
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: Wed, 11 Oct 2006 15:55:13 +0200 [thread overview]
Message-ID: <1160574913.3000.378.camel@laptopd505.fenrus.org> (raw)
In-Reply-To: <m17iz7m4xr.fsf@ebiederm.dsl.xmission.com>
On Wed, 2006-10-11 at 06:07 -0600, Eric W. Biederman wrote:
> Arjan van de Ven <arjan@infradead.org> writes:
>
> > On Tue, 2006-10-10 at 17:54 -0600, Eric W. Biederman wrote:
> >
> >> For processes shared pages are not special.
>
> Actually the above is not quite true you can map a shared page twice
> into the same process but in practice it rarely happens.
yeah I'm entirely fine with ignoring that case (or making the person who
does it pay for it :)
>
> > depends on what question you want to answer with RSS.
> > If the question is "workload working set size" then you are right. If
> > the question is "how much ram does my application cause to be used" the
> > answer is FAR less clear....
>
> There are two basic concerns. How do you keep an application from
> going crazy and trashing the rest of your system? A question on what
> number do you need to implement a resource limit.
yet at the same time if 2 apps mmap a shared file, and app 1 keeps it in
pagecache, it doesn't cause app2 to trash, or rather, it's not like if
app 2 did NOT have the page from that file, the system wouldn't trash.
> > You seem to have an implicit definition on what RSS should mean; but
> > it's implicit. Mind making an explicit definition of what RSS should be
> > in your opinion? I think that's the biggest problem we have right now;
> > several people have different ideas about what it should/could be, and
> > as such we're not talking about the same thing. Lets first agree/specify
> > what it SHOULD mean, and then we can figure out what gets counted for
> > that ;)
>
> Well I tried to defined it in terms of what you can use it for.
>
> I would define the resident set size as the total number of bytes
> of physical RAM that a process (or set of processes) is using,
> irrespective of the rest of the system.
>
>
> So I think the counting should be primarily about what is mapped into
> the page tables. But other things can be added as is appropriate or
> easy.
>
> The practical effect should be that an application that needs more
> pages than it's specified RSS to avoid thrashing should thrash but
> it shouldn't take the rest of the system with it.
so by your definition, hugepages are part of RSS.
Ken: what is your definition of RSS ?
--
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>
next prev parent reply other threads:[~2006-10-11 13:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20061010000928.9d2d519a.akpm@osdl.org>
[not found] ` <1160464800.3000.264.camel@laptopd505.fenrus.org>
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
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 [this message]
2006-10-11 17:15 ` Chen, Kenneth W
2006-10-11 22:36 ` Benjamin LaHaise
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=1160574913.3000.378.camel@laptopd505.fenrus.org \
--to=arjan@infradead.org \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@osdl.org \
--cc=ebiederm@xmission.com \
--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