linux-kernel - Re: [-mm patch] Show memcg information during OOM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20090203044123.GL918@balbir.in.ibm.com>
Date:	Tue, 3 Feb 2009 10:11:23 +0530
From:	Balbir Singh <balbir@...ux.vnet.ibm.com>
To:	David Rientjes <rientjes@...gle.com>
Cc:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"nishimura@....nes.nec.co.jp" <nishimura@....nes.nec.co.jp>,
	"lizf@...fujitsu.com" <lizf@...fujitsu.com>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [-mm patch] Show memcg information during OOM

* David Rientjes <rientjes@...gle.com> [2009-02-02 13:05:02]:

> 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, ...);
> 
> > +}
>

Thanks for the review, I'll incorporate as much of it as possible in
the next version. 

-- 
	Balbir
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/