lkml.org 
[lkml]   [2015]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: can't oom-kill zap the victim's memory?
    From
    Date
    Oleg Nesterov wrote:
    > On 09/17, Kyle Walker wrote:
    > >
    > > Currently, the oom killer will attempt to kill a process that is in
    > > TASK_UNINTERRUPTIBLE state. For tasks in this state for an exceptional
    > > period of time, such as processes writing to a frozen filesystem during
    > > a lengthy backup operation, this can result in a deadlock condition as
    > > related processes memory access will stall within the page fault
    > > handler.
    >
    > And there are other potential reasons for deadlock.
    >
    > Stupid idea. Can't we help the memory hog to free its memory? This is
    > orthogonal to other improvements we can do.

    So, we are trying to release memory without waiting for arriving at
    exit_mm() from do_exit(), right? If it works, it will be a simple and
    small change that will be easy to backport.

    The idea is that since fatal_signal_pending() tasks no longer return to
    user space, we can release memory allocated for use by user space, right?

    Then, I think that this approach can be applied to not only OOM-kill case
    but also regular kill(pid, SIGKILL) case (i.e. kick from signal_wake_up(1)
    or somewhere?). A dedicated kernel thread (not limited to OOM-kill purpose)
    scans for fatal_signal_pending() tasks and release that task's memory.


    \
     
     \ /
      Last update: 2015-09-20 17:21    [W:4.613 / U:0.032 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site