linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: bill4carson <bill4carson@gmail.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: Why memory.usage_in_bytes is always increasing after every mmap/dirty/unmap sequence
Date: Fri, 23 Mar 2012 17:19:03 +0900	[thread overview]
Message-ID: <4F6C31F7.2010804@jp.fujitsu.com> (raw)
In-Reply-To: <4F6C2E9B.9010200@gmail.com>

(2012/03/23 17:04), bill4carson wrote:

> Hi, all
> 
> I'm playing with memory cgroup, I'm a bit confused why
> memory.usage in bytes is steadily increasing at 4K page pace
> after every mmap/dirty/unmap sequence.
> 
> On linux-3.6.34.10/linux-3.3.0-rc5
> A simple test case does following:
> 
> a) mmap 128k memory in private anonymous way
> b) dirty all 128k to demand physical page
> c) print memory.usage_in_bytes  <-- increased at 4K after every loop
> d) unmap previous 128 memory
> e) goto a) to repeat

In Documentation/cgroup/memory.txt
==
5.5 usage_in_bytes

For efficiency, as other kernel components, memory cgroup uses some optimization
to avoid unnecessary cacheline false sharing. usage_in_bytes is affected by the
method and doesn't show 'exact' value of memory(and swap) usage, it's an fuzz
value for efficient access. (Of course, when necessary, it's synchronized.)
If you want to know more exact memory usage, you should use RSS+CACHE(+SWAP)
value in memory.stat(see 5.2).
==

In current implementation, memcg tries to charge resource in size of 32 pages.
So, if you get 32 pages and free 32pages, usage_in_bytes may not change.
This is affected by caches in other cpus and other flushing operations caused
by some workload in other cgroups. memcg's usage_in_bytes is not precise in
128k degree.

- How memory.stat changes ?
- What happens when you do test with 4M alloc/free ?

Thanks,
-Kame








--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2012-03-23  8:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-23  8:04 bill4carson
2012-03-23  8:19 ` KAMEZAWA Hiroyuki [this message]
2012-03-23  8:43   ` bill4carson
2012-03-23  8:59   ` bill4carson
2012-03-23  9:04     ` KAMEZAWA Hiroyuki
2012-03-23  9:15       ` bill4carson
2012-03-23  9:57         ` KAMEZAWA Hiroyuki
2012-03-27  8:26     ` Glauber Costa

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=4F6C31F7.2010804@jp.fujitsu.com \
    --to=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=bill4carson@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox