From: Anton Vorontsov <anton.vorontsov@linaro.org>
To: cgroups@vger.kernel.org
Cc: Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@suse.cz>,
Balbir Singh <bsingharora@gmail.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
John Stultz <john.stultz@linaro.org>
Subject: [RFC] memcg usage_in_bytes does not account file mapped and slab memory
Date: Fri, 2 Mar 2012 20:27:53 +0400 [thread overview]
Message-ID: <20120302162753.GA11748@oksana.dev.rtsoft.ru> (raw)
... and thus is useless for low memory notifications.
Hi all!
While working on userspace low memory killer daemon (a supposed
substitution for the kernel low memory killer, i.e.
drivers/staging/android/lowmemorykiller.c), I noticed that current
cgroups memory notifications aren't suitable for such a daemon.
Suppose we want to install a notification when free memory drops below
8 MB. Logically (taking memory hotplug aside), using current usage_in_bytes
notifications we would install an event on 'total_ram - 8MB' threshold.
But as usage_in_bytes doesn't account file mapped memory and memory
used by kernel slab, the formula won't work.
Currently I use the following patch that makes things going:
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 228d646..c8abdc5 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -3812,6 +3812,9 @@ static inline u64 mem_cgroup_usage(struct mem_cgroup *memcg, bool swap)
val = mem_cgroup_recursive_stat(memcg, MEM_CGROUP_STAT_CACHE);
val += mem_cgroup_recursive_stat(memcg, MEM_CGROUP_STAT_RSS);
+ val += mem_cgroup_recursive_stat(memcg, MEM_CGROUP_STAT_FILE_MAPPED);
+ val += global_page_state(NR_SLAB_RECLAIMABLE);
+ val += global_page_state(NR_SLAB_UNRECLAIMABLE);
But here are some questions:
1. Is there any particular reason we don't currently account file mapped
memory in usage_in_bytes?
To me, MEM_CGROUP_STAT_FILE_MAPPED hunk seems logical even if we
don't use it for lowmemory notifications.
Plus, it seems that FILE_MAPPED _is_ accounted for the non-root
cgroups, so I guess it's clearly a bug for the root memcg?
2. As for NR_SLAB_RECLAIMABLE and NR_SLAB_UNRECLAIMABLE, it seems that
these numbers are only applicable for the root memcg.
I'm not sure that usage_in_bytes semantics should actually account
these, but I tend to think that we should.
All in all, not accounting both 1. and 2. looks like bugs to me.
But if for some reason we don't want to change usage_in_bytes, should
I just go ahead and implement a new cftype (say free_in_bytes), which
would account free memory as total_ram - cache - rss - mapped - slab,
with ability to install notifiers? That way we would also could solve
memory hotplug issue in the kernel, so that userland won't need to
bother with reinstalling lowmemory notifiers when memory added/removed.
Thanks!
--
Anton Vorontsov
Email: cbouatmailru@gmail.com
--
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>
next reply other threads:[~2012-03-02 16:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-02 16:27 Anton Vorontsov [this message]
2012-03-05 0:19 ` [RFC] memcg usage_in_bytes does not account file mapped and slab memory KAMEZAWA Hiroyuki
2012-04-23 8:28 ` [PATCH RFC] memcg: MEMCG_NR_FILE_MAPPED should update _STAT_CACHE as well Anton Vorontsov
2012-04-23 8:35 ` KAMEZAWA Hiroyuki
2012-04-23 9:33 ` Anton Vorontsov
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=20120302162753.GA11748@oksana.dev.rtsoft.ru \
--to=anton.vorontsov@linaro.org \
--cc=akpm@linux-foundation.org \
--cc=bsingharora@gmail.com \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=john.stultz@linaro.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kosaki.motohiro@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
/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;
as well as URLs for NNTP newsgroup(s).