linux-kernel - Re: abnormal OOM killer message

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Wed, 19 Aug 2009 13:51:05 +0900
From:	Minchan Kim <minchan.kim@...il.com>
To:	ngupta@...are.org
Cc:	Minchan Kim <minchan.kim@...il.com>,
	우충기 <chungki.woo@...il.com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	fengguang.wu@...el.com, riel@...hat.com, akpm@...ux-foundation.org,
	kosaki.motohiro@...fujitsu.com, Mel Gorman <mel@....ul.ie>
Subject: Re: abnormal OOM killer message


On Wed, 19 Aug 2009 09:14:08 +0530
Nitin Gupta <ngupta@...are.org> wrote:

> On 08/19/2009 08:14 AM, Minchan Kim wrote:
> > On Wed, 19 Aug 2009 10:41:51 +0900
> > 우충기<chungki.woo@...il.com>  wrote:
> >
> >> Hi all~
> >> I have got a log message with OOM below. I don't know why this
> >> phenomenon was happened.
> >> When direct reclaim routine(try_to_free_pages) in __alloc_pages which
> >> allocates kernel memory was failed,
> >> one last chance is given to allocate memory before OOM routine is executed.
> >> And that time, allocator uses ALLOC_WMARK_HIGH to limit watermark.
> >> Then, zone_watermark_ok function test this value with current memory
> >> state and decide 'can allocate' or 'cannot allocate'.
> >>
> >> Here is some kernel source code in __alloc_pages function to understand easily.
> >> Kernel version is 2.6.18 for arm11. Memory size is 32Mbyte. And I use
> >> compcache(0.5.2).
> 
> <snip>
> 
> >>
> >> In my case, you can see free pages(6804KB) is much more higher than
> >> high watermark value(1084KB) in OOM message.
> >> And order of allocating is also zero.(order=0)
> >> In buddy system, the number of 4kbyte page is 867.
> >> So, I think OOM can't be happend.
> >>
> >
> > Yes. I think so.
> >
> > In that case, even we can also avoid zone defensive algorithm.
> >
> >> How do you think about this?
> >> Is this side effect of compcache?
> >
> 
> compcache can be storing lot of stale data and this memory space cannot be
> reclaimed (unless overwritten by some other swap data). This is because

stale data. It seems related ARMv6. 
I think Chungki's CPU is ARMv6. 

> compcache does not know when a swap slot has been freed and hence does not know 
> when its safe to free corresponding memory. You can check current memory usage 
> with /proc/ramzswap (see MemUsedTotal).
> 

Let me have a question. 
Now the system has 79M as total swap. 
It's bigger than system memory size. 
Is it possible in compcache?
Can we believe the number?

> BTW, with compcache-0.6 there is an experimental kernel patch that gets rid of 
> all this stale data:
> http://patchwork.kernel.org/patch/41083/
> 
> However, this compcache version needs at least kernel 2.6.28. This version also 
> fixes all known problems on ARM. compcache-0.5.3 or earlier is known to crash on 
> ARM (see: http://code.google.com/p/compcache/issues/detail?id=33).
>

Chungki. Is it reproducible easily ?
Could you try it with compcache-0.6. 
As Nitin said, it seems to solve cache aliasing problem. 

> Thanks,
> Nitin


-- 
Kind regards,
Minchan Kim
--
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/