Re: 2.6.28-rc4 mem_cgroup_charge_common panic

[KAMEZAWA Hiroyuki]

On Wed, 12 Nov 2008 14:02:56 -0800
Badari Pulavarty <pbadari@xxxxxxxxxx> wrote:

> On Tue, 2008-11-11 at 11:09 +0900, KAMEZAWA Hiroyuki wrote:
> > On Tue, 11 Nov 2008 10:14:40 +0900
> > KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote:
> > 
> > > On Mon, 10 Nov 2008 13:43:28 -0800
> > > Badari Pulavarty <pbadari@xxxxxxxxxx> wrote:
> > > 
> > > > Hi KAME,
> > > > 
> > > > Thank you for the fix for online/offline page_cgroup panic.
> > > > 
> > > > While running memory offline/online tests ran into another
> > > > mem_cgroup panic.
> > > > 
> > > 
> > > Hm, should I avoid freeing mem_cgroup at memory Offline ?
> > > (memmap is also not free AFAIK.)
> > > 
> > > Anyway, I'll dig this. thanks.
> > > 
> > it seems not the same kind of bug..
> > 
> > Could you give me disassemble of mem_cgroup_charge_common() ?
> > (I'm not sure I can read ppc asm but I want to know what is "0x20"
> >  of fault address....)
> > 
> > As first impression, it comes from page migration..
> > rc4's page migration handler of memcg handles *usual* path but not so good.
> > 
> > new migration code of memcg in mmotm is much better, I think.
> > Could you try mmotm if you have time ?
> 
> I tried mmtom. Its even worse :(
> 
> Ran into following quickly .. Sorry!!
> 
>From 
> Instruction dump:
> 794b1f24 794026e4 7d6bda14 7d3b0214 7d234b78 39490008 e92b0048 39290001 
> f92b0048 419e001c e9230008 f93c0018 <f9090008> f9030008 f9480008 48000018 

the reason doesn't seem to be different from the one you saw in rc4.

We'do add_list() hear, so (maybe) used page_cgroup is zero-cleared, I think.
We usually do migration test on cpuset and confirmed this works with migration.

Hmm...I susupect following. could you try ?

Sorry.
-Kame
==

Index: mmotm-2.6.28-Nov10/mm/page_cgroup.c
===================================================================
--- mmotm-2.6.28-Nov10.orig/mm/page_cgroup.c
+++ mmotm-2.6.28-Nov10/mm/page_cgroup.c
@@ -166,7 +166,7 @@ int online_page_cgroup(unsigned long sta
 	end = ALIGN(start_pfn + nr_pages, PAGES_PER_SECTION);
 
 	for (pfn = start; !fail && pfn < end; pfn += PAGES_PER_SECTION) {
-		if (!pfn_present(pfn))
+		if (!pfn_valid(pfn))
 			continue;
 		fail = init_section_page_cgroup(pfn);
 	}



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