Re: oom_killer crash linux system

[KOSAKI Motohiro]

> 
> > > page_add_file_rmap() just counts an event where mapcount goes 0->1. 
> > > Even if thousands process shares  a page,  it's just counted into file_mapped as 1.
> > > 
> > > Then, there are 480MB of mapped file caches. Do I miss something ?
> > > 
> > > Anyway, sum-of-all-lru-of-highmem is 480MB smaller than present pages.
> > > and isolated(anon/file) is 0kB.
> > > (NORMAL has similar problem)
> > 
> > hugetlb files? But it's a desktop box. Figo, what's your meminfo?
> > 
> > The GEM objects may be files not in LRU, however they should be
> > accounted into shmem.
> > 
> > Figo, would you run "page-types -r" for some clues? It can be compiled
> > from the kernel tree:
> > 
> >         cd linux
> >         make Documentation/vm
> >         sudo Documentation/vm/page-types -r
> 
> hi fengguang,
> here is the "page-types -r" result:
> 
>              flags	page-count       MB  symbolic-flags
> long-symbolic-flags
> 0x0000000000005828	     74342      290 ___U_l_____Ma_b___________________ uptodate,lru,mmap,anonymous,swapbacked
> 0x0000000000005868	    373077     1457 ___U_lA____Ma_b___________________ uptodate,lru,active,mmap,anonymous,swapbacked

1457+290=1747MB. that's ok. and this is very different result with your
previous oom log.

can you please try 1) invoke oom 2) get page-types -r again. I'm curious
that oom makes page accounting lost again. I mean, please send us oom 
log and "page-types -r" result.

thanks.




--
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/