Messages in this thread | | | Date | Sat, 4 Dec 2004 17:43:53 +0100 | From | Andrea Arcangeli <> | Subject | Re: [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: > > http://marc.theaimsgroup.com/?l=linux-kernel&m=110204117506557&w=2
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-2.15.92.0.2 > > 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 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/
| |