[lkml]   [2004]   [Dec]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] oom killer (Core)
On Sat, Dec 04, 2004 at 01:42:54PM +0100, Voluspa wrote:
> 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
> with
> > 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:

yes it's the right one ;)

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

I trust you of course but I've absolutely no idea how can my patch ever
change any code that runs at that point during boot. mm/oom_kill.c can
be obviously ruled out. The changes in mm/swap_state.c (two printk in
show_swap_cache_info) as well can be obviously ruled out. The change in
mm/vmscan.c as well only makes a difference during an oom condition.

This mean it has to be the change in mm/page_alloc.c that broke
something. But even that should never run during boot (except for the
cond_resched instead of might_sleep_if that you already tried to backout
separately from the rest). There's simply not enough memory pressure at
boot in order to recall try_to_free_pages and run the modified code.

If try_to_free_pages is being recalled during boot them we've a problem
somewhere else, it should never happen!

Plus it works like a charm here.

Can you send me your .config so that I will try to send you privately a
kernel image built on my machine? (and before sending I'll try to boot
it locally ;) My .config sure is happily running.

Many thanks.
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.059 / U:0.716 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site