lkml.org 
[lkml]   [2009]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: abnormal OOM killer message

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

    > 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

    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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2009-08-19 06:55    [W:0.030 / U:0.568 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site