All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: "Chen, Kenneth W" <kenneth.w.chen@intel.com>
Cc: 'Hugh Dickins' <hugh@veritas.com>,
	'Andrew Morton' <akpm@osdl.org>,
	linux-mm@kvack.org, arjan <arjan@infradead.org>
Subject: Re: [patch 2/2] htlb forget rss with pt sharing
Date: Sat, 21 Oct 2006 17:58:41 +0200	[thread overview]
Message-ID: <1161446321.5230.69.camel@lappy> (raw)
In-Reply-To: <000101c6f3b2$7f9cf980$ff0da8c0@amr.corp.intel.com>

On Thu, 2006-10-19 at 12:12 -0700, Chen, Kenneth W wrote:
> Imprecise RSS accounting is an irritating ill effect with pt sharing. 
> After consulted with several VM experts, I have tried various methods to
> solve that problem: (1) iterate through all mm_structs that share the PT
> and increment count; (2) keep RSS count in page table structure and then
> sum them up at reporting time.  None of the above methods yield any
> satisfactory implementation.
> 
> Since process RSS accounting is pure information only, I propose we don't
> count them at all for hugetlb page. rlimit has such field, though there is
> absolutely no enforcement on limiting that resource.  One other method is
> to account all RSS at hugetlb mmap time regardless they are faulted or not.
> I opt for the simplicity of no accounting at all.

I do feel I must object to this. Especially with hugetlb getting real
accessible with libhugetlbfs etc., I suspect administrators will shortly
be confused where all their memory went.

Also, like stated earlier, I don't like breaking RSS accounting now, and
when we do have thought up a valid meaning for the field, again. You
state correctly that RLIMIT_RSS is currently not enforced, but its an
active area int that we do want to enforce it in the near future.

I do grant its a very hard problem, comming up with a
valid/meaningfull/workable definition of RSS, but I dislike this opt out
of just not counting it at all - and thereby making the effort of
enforcing RSS harder.

Just my 0.02 eurocent ;-)



--
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>

  reply	other threads:[~2006-10-21 15:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-19 19:12 [patch 2/2] htlb forget rss with pt sharing Chen, Kenneth W
2006-10-21 15:58 ` Peter Zijlstra [this message]
2006-10-22 21:28   ` Chen, Kenneth W
  -- strict thread matches above, loose matches on Subject: below --
2006-10-03 10:01 Chen, Kenneth W

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=1161446321.5230.69.camel@lappy \
    --to=a.p.zijlstra@chello.nl \
    --cc=akpm@osdl.org \
    --cc=arjan@infradead.org \
    --cc=hugh@veritas.com \
    --cc=kenneth.w.chen@intel.com \
    --cc=linux-mm@kvack.org \
    /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.