Re: Possible dcache BUG
From: Nick Piggin (nickpiggin_at_yahoo.com.au)
Date: 08/24/04
- Previous message: formationun_at_netcourrier.com: "Qlaboration=20d'un=20plan=20de=20formation?="
- In reply to: Udo A. Steinberg: "Re: Possible dcache BUG"
- Next in thread: Marcelo Tosatti: "Re: Possible dcache BUG"
- Reply: Marcelo Tosatti: "Re: Possible dcache BUG"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 24 Aug 2004 17:41:07 +1000 To: "Udo A. Steinberg" <us15@os.inf.tu-dresden.de>
Udo A. Steinberg wrote:
>On Fri, 20 Aug 2004 17:49:55 +1000 Nick Piggin (NP) wrote:
>
>NP> Can you reproduce the OOM with the following patch please? Then
>NP> send the output.
>
>I reproduced the problem using a slightly different setup to trigger the
>problem faster: 128 MB RAM, 188992 KB swap
>
>Here's the output of the OOM killer with your patch applied:
>
>oom-killer: gfp_mask=0x1d2
>DMA per-cpu:
>cpu 0 hot: low 2, high 6, batch 1
>cpu 0 cold: low 0, high 2, batch 1
>Normal per-cpu:
>cpu 0 hot: low 14, high 42, batch 7
>cpu 0 cold: low 0, high 14, batch 7
>HighMem per-cpu: empty
>
>Free pages: 1316kB (0kB HighMem)
>Active:5281 inactive:23611 dirty:0 writeback:0 unstable:0 free:329 slab:1403 mapped:12232 pagetables:167
>DMA free:712kB min:44kB low:88kB high:132kB active:5076kB inactive:5332kB present:16384kB pages_scanned:10112 all_unreclaimable? yes
>protections[]: 22 178 178
>Normal free:604kB min:312kB low:624kB high:936kB active:16048kB inactive:89112kB present:114688kB pages_scanned:62432 all_unreclaimable? yes
>protections[]: 0 156 156
>HighMem free:0kB min:128kB low:256kB high:384kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
>protections[]: 0 0 0
>DMA: 0*4kB 3*8kB 13*16kB 1*32kB 1*64kB 1*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 712kB
>Normal: 1*4kB 1*8kB 1*16kB 0*32kB 1*64kB 0*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 604kB
>HighMem: empty
>Swap cache: add 90886, delete 74524, find 4659/4974, race 0+0
>Out of Memory: Killed process 1217 (gphoto2).
>
>
OK, all_unreclaimable caused the scanner to virtually stop. If
all_unreclaimable
gets set, it throttles the scanning of that zone right back, which in
turn greatly
lowers the chance that all_unreclaimable will get cleared.
When we get to priority = 0 in try_to_free_pages (ie. close to OOM), it
might be
worth clearing each zone's all_unreclaimable for this last time 'round
the loop.
-
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/
- Previous message: formationun_at_netcourrier.com: "Qlaboration=20d'un=20plan=20de=20formation?="
- In reply to: Udo A. Steinberg: "Re: Possible dcache BUG"
- Next in thread: Marcelo Tosatti: "Re: Possible dcache BUG"
- Reply: Marcelo Tosatti: "Re: Possible dcache BUG"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
