Re: abnormal OOM killer message

[Nitin Gupta <ngupta@vflare.org>]

On 08/19/2009 08:14 AM, Minchan Kim wrote:
> On Wed, 19 Aug 2009 10:41:51 +0900
> 우충기<chungki.woo@gmail.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
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).

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).

Thanks,
Nitin