Messages in this thread | | | Subject | Re: [PATCH] oom killer (Core) | From | Thomas Gleixner <> | Date | Fri, 03 Dec 2004 23:37:17 +0100 |
| |
On Fri, 2004-12-03 at 03:28 +0100, Andrea Arcangeli wrote: > On Fri, Dec 03, 2004 at 12:34:59AM +0100, Andrea Arcangeli wrote: > > I'll add to my last patch the removal of the PF_MEMDIE check in oom_kill > > plus I'll fix the remaining race with PF_EXITING/DEAD, and I'll add a > > cond_resched. Then you can try again with my simple way (w/ and w/o > > PREEMPT ;). > > Ok, I expect this patch to fix the problem completely. > <SNIP> > With this thing, I doubt any wrong task will ever be killed again...
You're right. oom-kill() did not do anything wrong. See log below
This is w/o PREEMPT. Is it neccecary to verify w/ PREEMPT too ?
If it would have booted it still would have killed sshd instead of the application which was forking a lot of childs.
tglx
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 126476k/131060k available (1690k kernel code, 4044k reserved, 732k data)Checking if this processor honours the WP bit even in supervisor mode... Ok. Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 128K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: Intel Celeron (Mendocino) stepping 00 Enabling fast FPU save and restore... done. Checking 'hlt' instruction... OK.
END OF LOG
- 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/
| |