[lkml]   [2004]   [Dec]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] oom killer (Core)
    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.


    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.


    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:2.282 / U:0.508 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site