[lkml]   [2005]   [Jan]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH][2/2] do not OOM kill if we skip writing many pages
    On Mon, 3 Jan 2005, Andrea Arcangeli wrote:
    > On Mon, Jan 03, 2005 at 10:22:41AM -0200, Marcelo Tosatti wrote:
    >> What are the details of the OOM kills (output, workload, configuration, etc)?

    The workload is a simple dd to a block device, on a system
    with highmem. The mapping for the block device can only be
    cached in lowmem.

    kernel: oom-killer: gfp_mask=0xd0
    kernel: Free pages: 968016kB (966400kB HighMem)
    kernel: Active:31932 inactive:185316 dirty:8 writeback:165518 unstable:0 free:242004 slab:55830 mapped:33266 pagetables:1135
    kernel: DMA free:16kB min:16kB low:32kB high:48kB active:0kB inactive:9656kB present:16384kB
    kernel: protections[]: 0 0 0
    kernel: Normal free:1600kB min:936kB low:1872kB high:2808kB active:208kB inactive:653148kB present:901120kB
    kernel: protections[]: 0 0 0
    kernel: HighMem free:966400kB min:512kB low:1024kB high:1536kB active:127520kB inactive:78464kB present:1179584kB
    kernel: protections[]: 0 0 0

    If you run on a system with more highmem, you'll simply get
    an OOM kill with more free highmem pages. The only thing
    that lives in highmem is the process code, which the VM is
    not scanning for obvious reasons.

    >> Are these running 2.6.10-mm?

    The latest rawhide kernel, with a few VM fixes, including all
    the important ones that I could see from -mm.

    Reading balance_dirty_pages, I do not understand how we could
    end up having so many pages in writeback state, but still
    continue writing out more - surely we should have run out of
    dirty pages long ago and stalled in blk_congestion_wait()
    until lots of IO had finished completing ?

    Why can we build up 660MB of pages in the writeback stage,
    for a mapping that can only live in the low 900MB of memory?
    Yes, it has my patch 1/2 applied (lowering the dirty limit
    for lowmem only mappings)...

    > And did they apply Con's patch? (i.e. my 3/4 I posted few days ago)

    Con's patch is not relevant for this bug, since there are so few
    mapped pages (and those almost certainly live in highmem, which
    the VM is not scanning).

    "Debugging is twice as hard as writing the code in the first place.
    Therefore, if you write the code as cleverly as possible, you are,
    by definition, not smart enough to debug it." - Brian W. Kernighan
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:09    [W:0.021 / U:28.860 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site