From: David Rientjes <rientjes@google.com>
To: Balbir Singh <balbir@linux.vnet.ibm.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Andrew Morton <akpm@linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"nishimura@mxp.nes.nec.co.jp" <nishimura@mxp.nes.nec.co.jp>,
"lizf@cn.fujitsu.com" <lizf@cn.fujitsu.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [-mm patch] Show memcg information during OOM
Date: Mon, 2 Feb 2009 13:05:02 -0800 (PST) [thread overview]
Message-ID: <alpine.DEB.2.00.0902021256030.30674@chino.kir.corp.google.com> (raw)
In-Reply-To: <20090202205434.GI918@balbir.in.ibm.com>
On Tue, 3 Feb 2009, Balbir Singh wrote:
> David, I'd agree, but since we are under printk_ratelimit() and this
> is a not-so-common path, does the log level matter much? If it does, I
> don't mind using KERN_INFO.
>
It matters for parsing dmesg output; the only KERN_WARNING message from
the oom killer is normally the header. There's a couple extra ones for
error conditions (that could certainly be changed to KERN_ERR), but only
in very rare circumstances.
As defined by include/linux/kernel.h:
#define KERN_WARNING "<4>" /* warning conditions */
...
#define KERN_INFO "<6>" /* informational */
The meminfo you are printing falls under the "informational" category, no?
While you're there, it might also be helpful to make another change
that would also help in parsing the output:
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 8e4be9c..954b0d5 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -813,6 +813,25 @@ bool mem_cgroup_oom_called(struct task_struct *task)
> rcu_read_unlock();
> return ret;
> }
> +
> +void mem_cgroup_print_mem_info(struct mem_cgroup *memcg)
> +{
> + if (!memcg)
> + return;
> +
> + printk(KERN_WARNING "Memory cgroups's name %s\n",
> + memcg->css.cgroup->dentry->d_name.name);
This should be "cgroup's", but I don't think you want to print this on a
line by itself since the only system-wide synchronization here is a
read-lock on tasklist_lock and there could be two separate memcg's that
are oom.
So it's quite possible, though unlikely, that two seperate oom events
would have these messages merged together in the ring buffer, which would
make parsing impossible.
I think you probably want to add the name to each line you print, such as:
> + printk(KERN_WARNING "Cgroup memory: usage %llu, limit %llu"
> + " failcnt %llu\n", res_counter_read_u64(&memcg->res, RES_USAGE),
> + res_counter_read_u64(&memcg->res, RES_LIMIT),
> + res_counter_read_u64(&memcg->res, RES_FAILCNT));
const char *name = memcg->css.cgroup->dentry->d_name.name;
printk(KERN_INFO "Cgroup %s memory: usage %llu, limit %llu"
" failcount %llu\n", name, ...);
> + printk(KERN_WARNING "Cgroup memory+swap: usage %llu, limit %llu "
> + "failcnt %llu\n",
> + res_counter_read_u64(&memcg->memsw, RES_USAGE),
> + res_counter_read_u64(&memcg->memsw, RES_LIMIT),
> + res_counter_read_u64(&memcg->memsw, RES_FAILCNT));
and
printk(KERN_INFO "Cgroup %s memory+swap: usage %llu, limit %llu "
"failcnt %llu\n", name, ...);
> +}
--
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:[~2009-02-02 21:05 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-02 12:52 Balbir Singh
2009-02-02 12:59 ` KOSAKI Motohiro
2009-02-02 14:12 ` Balbir Singh
2009-02-02 14:17 ` Balbir Singh
2009-02-02 20:37 ` David Rientjes
2009-02-02 20:54 ` Balbir Singh
2009-02-02 21:05 ` David Rientjes [this message]
2009-02-03 4:41 ` Balbir Singh
2009-02-03 5:41 ` Balbir Singh
2009-02-03 5:45 ` David Rientjes
2009-02-02 13:45 ` Johannes Weiner
2009-02-03 3:44 ` Daisuke Nishimura
2009-02-03 5:55 ` Daisuke Nishimura
2009-02-03 6:04 ` David Rientjes
2009-02-02 14:08 ` Balbir Singh
2009-02-03 1:21 ` KAMEZAWA Hiroyuki
2009-02-03 4:34 ` Balbir Singh
2009-02-03 1:29 ` Li Zefan
2009-02-03 4:41 ` Balbir Singh
2009-02-03 4:47 ` David Rientjes
2009-02-03 4:55 ` Balbir Singh
2009-02-03 5:25 ` David Rientjes
2009-02-03 5:33 ` Balbir Singh
2009-02-03 5:24 ` Li Zefan
2009-02-03 5:35 ` Balbir Singh
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=alpine.DEB.2.00.0902021256030.30674@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=akpm@linux-foundation.org \
--cc=balbir@linux.vnet.ibm.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizf@cn.fujitsu.com \
--cc=nishimura@mxp.nes.nec.co.jp \
/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