[lkml]   [2004]   [Dec]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] oom killer (Core)

On 2004-12-04 8:08:40 Andrea Arcangeli wrote:

> You can try to put back a might_slee_if(wait), but if it deadlocks
> that change sure it's not a bug in my patch, it's instead a bug
> somewhere else that calls alloc_pages w/o GFP_ATOMIC. Ingo's
> lowlatency patch would expose the same bug too since they're aliasing
> the might_sleep to cond_resched.

Putting it back doesn't alter the outcome - hanging. And the original
patch, (hope it was the right one) from:

root:loke:/usr/src/linux-2.6.9-oomkill# patch -Np1 -i ../oomkill.patch
patching file mm/oom_kill.c
patching file mm/page_alloc.c
Hunk #1 succeeded at 608 (offset -3 lines).
Hunk #3 succeeded at 681 (offset -3 lines).
patching file mm/swap_state.c
patching file mm/vmscan.c

has been tried with the following variations. With and without
optimizing for size, with and without preempt, with and without kernel
boot params (cfq, lapic), cold and hot starts, and then I threw in a smp
compile for measure. All have the same behaviour:

Checking 'hlt' instruction... OK.

[10 minutes wait. Then a long callback trace
scrolls off the screen ending like Thomas']

<0>Kernel panic - not syncing: Fatal exception in interrupt

My toolchain (well, the whole software system) is quite contemporary
within the stable branches. Built from scratch with gcc-3.4.3, glibc-
20041011 (nptl) and binutils-

No energy control, acpi-pm or whatever it's called, is used here. The
machine is extremely stable. Running with 100 percent utilization 24/7.

Don't shoot the messenger ;)
Mats Johannesson

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:08    [W:0.038 / U:6.180 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site