lkml.org 
[lkml]   [2015]   [Sep]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: can't oom-kill zap the victim's memory?
    On Mon 21-09-15 15:44:14, Oleg Nesterov wrote:
    [...]
    > So yes, in general oom_kill_process() can't call oom_unmap_func() directly.
    > That is why the patch uses queue_work(oom_unmap_func). The workqueue thread
    > takes mmap_sem and frees the memory allocated by user space.

    OK, this might have been a bit confusing. I didn't mean you cannot use
    mmap_sem directly from the workqueue context. You _can_ AFAICS. But I've
    mentioned that you _shouldn't_ use workqueue context in the first place
    because all the workers might be blocked on locks and new workers cannot
    be created due to memory pressure. This has been demostrated already
    where sysrq+f couldn't trigger OOM killer because the work item to do so
    was waiting for a worker which never came...

    So I think we probably need to do this in the OOM killer context (with
    try_lock) or hand over to a special kernel thread. I am not sure a
    special kernel thread is really worth that but maybe it will turn out to
    be a better choice.
    --
    Michal Hocko
    SUSE Labs


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