Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1229524

Re: can't oom-kill zap the victim's memory?

From Michal Hocko <mhocko@kernel.org>
Newsgroups linux.kernel
Subject Re: can't oom-kill zap the victim's memory?
Date 2015-09-21 18:20 +0200
Message-ID <qbbYS-3k6-5@gated-at.bofh.it> (permalink)
References (3 earlier) <qaMxt-IY-11@gated-at.bofh.it> <qaRdM-7oP-19@gated-at.bofh.it> <qb9DJ-8gq-37@gated-at.bofh.it> <qbagr-O0-23@gated-at.bofh.it> <qbbma-2la-21@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw

On Mon 21-09-15 17:32:52, Oleg Nesterov wrote:
> On 09/21, Michal Hocko wrote:
> >
> > 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.
> 
> Yes, yes, and I already tried to comment this part.

OK then we are on the same page, good.

> We probably need a
> dedicated kernel thread, but I still think (although I am not sure) that
> initial change can use workueue. In the likely case system_unbound_wq pool
> should have an idle thread, if not - OK, this change won't help in this
> case. This is minor.

The point is that the implementation should be robust from the very
beginning. I am not sure what you mean by the idle thread here but the
rescuer can get stuck the very same way other workers. So I think that
we cannot rely on WQ for a real solution here.

> > So I think we probably need to do this in the OOM killer context (with
> > try_lock)
> 
> Yes we should try to do this in the OOM killer context, and in this case
> (of course) we need trylock. Let me quote my previous email:
> 
> 	And we want to avoid using workqueues when the caller can do this
> 	directly. And in this case we certainly need trylock. But this needs
> 	some refactoring: we do not want to do this under oom_lock,

Why do you think oom_lock would be a big deal? Address space of the
victim might be really large but we can back off after a batch of
unmapped pages.

>       otoh it
> 	makes sense to do this from mark_oom_victim() if current && killed,
> 	and a lot more details.
> 
> and probably this is another reason why do we need MMF_MEMDIE. But again,
> I think the initial change should be simple.

I definitely agree with the simplicity for the first iteration. That
means only unmap private exclusive pages and release at most few megs of
them. I am still not sure about some details, e.g. futex sitting in such
a memory. Wouldn't threads blow up when they see an unmapped futex page,
try to page it in and it would be in an uninitialized state? Maybe this
is safe because they will die anyway but I am not familiar with that
code.
-- 
Michal Hocko
SUSE Labs
--
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/

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks Kyle Walker <kwalker@redhat.com> - 2015-09-17 20:10 +0200
  Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks Oleg Nesterov <oleg@redhat.com> - 2015-09-17 21:30 +0200
    Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks Christoph Lameter <cl@linux.com> - 2015-09-18 17:50 +0200
      Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks Oleg Nesterov <oleg@redhat.com> - 2015-09-18 18:30 +0200
        Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2015-09-18 18:50 +0200
          Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks Oleg Nesterov <oleg@redhat.com> - 2015-09-18 19:00 +0200
        Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks Christoph Lameter <cl@linux.com> - 2015-09-18 19:10 +0200
          Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks Oleg Nesterov <oleg@redhat.com> - 2015-09-18 21:20 +0200
            Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks Christoph Lameter <cl@linux.com> - 2015-09-18 21:20 +0200
              Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks Christoph Lameter <cl@linux.com> - 2015-09-19 00:10 +0200
          Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks Michal Hocko <mhocko@kernel.org> - 2015-09-19 10:40 +0200
            Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2015-09-19 16:40 +0200
              Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks Michal Hocko <mhocko@kernel.org> - 2015-09-19 18:00 +0200
              Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks David Rientjes <rientjes@google.com> - 2015-09-22 01:40 +0200
                Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2015-09-22 07:40 +0200
                Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks David Rientjes <rientjes@google.com> - 2015-09-23 01:40 +0200
                Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks Kyle Walker <kwalker@redhat.com> - 2015-09-23 14:10 +0200
                Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2015-09-24 14:00 +0200
            Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks Oleg Nesterov <oleg@redhat.com> - 2015-09-19 16:50 +0200
          Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks David Rientjes <rientjes@google.com> - 2015-09-22 01:30 +0200
      Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks Michal Hocko <mhocko@kernel.org> - 2015-09-19 10:30 +0200
  Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks Michal Hocko <mhocko@kernel.org> - 2015-09-19 10:30 +0200
    Re: [PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks David Rientjes <rientjes@google.com> - 2015-09-22 01:10 +0200
  can't oom-kill zap the victim's memory? Oleg Nesterov <oleg@redhat.com> - 2015-09-19 17:10 +0200
    Re: can't oom-kill zap the victim's memory? Oleg Nesterov <oleg@redhat.com> - 2015-09-19 17:20 +0200
    Re: can't oom-kill zap the victim's memory? Michal Hocko <mhocko@kernel.org> - 2015-09-19 18:00 +0200
      Re: can't oom-kill zap the victim's memory? Oleg Nesterov <oleg@redhat.com> - 2015-09-20 15:20 +0200
    Re: can't oom-kill zap the victim's memory? Linus Torvalds <torvalds@linux-foundation.org> - 2015-09-20 00:30 +0200
      Re: can't oom-kill zap the victim's memory? Raymond Jennings <shentino@gmail.com> - 2015-09-20 01:10 +0200
        Re: can't oom-kill zap the victim's memory? Linus Torvalds <torvalds@linux-foundation.org> - 2015-09-20 01:20 +0200
      Re: can't oom-kill zap the victim's memory? Michal Hocko <mhocko@kernel.org> - 2015-09-20 11:40 +0200
        Re: can't oom-kill zap the victim's memory? Oleg Nesterov <oleg@redhat.com> - 2015-09-20 15:10 +0200
      Re: can't oom-kill zap the victim's memory? Oleg Nesterov <oleg@redhat.com> - 2015-09-20 15:10 +0200
        Re: can't oom-kill zap the victim's memory? Linus Torvalds <torvalds@linux-foundation.org> - 2015-09-20 20:10 +0200
          Re: can't oom-kill zap the victim's memory? Raymond Jennings <shentino@gmail.com> - 2015-09-20 21:10 +0200
            Re: can't oom-kill zap the victim's memory? Oleg Nesterov <oleg@redhat.com> - 2015-09-21 16:10 +0200
          Re: can't oom-kill zap the victim's memory? Oleg Nesterov <oleg@redhat.com> - 2015-09-21 15:50 +0200
            Re: can't oom-kill zap the victim's memory? Michal Hocko <mhocko@kernel.org> - 2015-09-21 16:30 +0200
              Re: can't oom-kill zap the victim's memory? Oleg Nesterov <oleg@redhat.com> - 2015-09-21 17:40 +0200
                Re: can't oom-kill zap the victim's memory? Michal Hocko <mhocko@kernel.org> - 2015-09-21 18:20 +0200
                Re: can't oom-kill zap the victim's memory? Oleg Nesterov <oleg@redhat.com> - 2015-09-22 18:10 +0200
                Re: can't oom-kill zap the victim's memory? David Rientjes <rientjes@google.com> - 2015-09-23 01:10 +0200
                Re: can't oom-kill zap the victim's memory? Michal Hocko <mhocko@kernel.org> - 2015-09-23 23:00 +0200
                Re: can't oom-kill zap the victim's memory? David Rientjes <rientjes@google.com> - 2015-09-24 23:20 +0200
                Re: can't oom-kill zap the victim's memory? Michal Hocko <mhocko@kernel.org> - 2015-09-25 11:40 +0200
                Re: can't oom-kill zap the victim's memory? Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2015-09-25 18:20 +0200
                Re: can't oom-kill zap the victim's memory? Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2015-09-28 18:20 +0200
                Re: can't oom-kill zap the victim's memory? David Rientjes <rientjes@google.com> - 2015-09-29 00:30 +0200
                Re: can't oom-kill zap the victim's memory? Michal Hocko <mhocko@kernel.org> - 2015-10-02 14:40 +0200
                Re: can't oom-kill zap the victim's memory? Linus Torvalds <torvalds@linux-foundation.org> - 2015-10-02 21:10 +0200
                Re: can't oom-kill zap the victim's memory? Michal Hocko <mhocko@kernel.org> - 2015-10-05 16:50 +0200
                Can't we use timeout based OOM warning/killing? Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2015-10-03 08:10 +0200
                Re: can't oom-kill zap the victim's memory? David Rientjes <rientjes@google.com> - 2015-09-29 00:30 +0200
                Re: can't oom-kill zap the victim's memory? Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2015-09-29 10:00 +0200
                Re: can't oom-kill zap the victim's memory? David Rientjes <rientjes@google.com> - 2015-09-30 01:00 +0200
                Re: can't oom-kill zap the victim's memory? Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2015-09-30 06:30 +0200
                Re: can't oom-kill zap the victim's memory? Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2015-09-30 12:30 +0200
                Re: can't oom-kill zap the victim's memory? David Rientjes <rientjes@google.com> - 2015-09-30 23:20 +0200
                Re: can't oom-kill zap the victim's memory? Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2015-10-01 14:20 +0200
                Re: can't oom-kill zap the victim's memory? Michal Hocko <mhocko@kernel.org> - 2015-10-01 16:50 +0200
                Re: can't oom-kill zap the victim's memory? Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2015-10-02 15:10 +0200
                Re: can't oom-kill zap the victim's memory? Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2015-09-21 19:00 +0200
                Re: can't oom-kill zap the victim's memory? Oleg Nesterov <oleg@redhat.com> - 2015-09-22 14:50 +0200
                Re: can't oom-kill zap the victim's memory? Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2015-09-22 16:40 +0200
                Re: can't oom-kill zap the victim's memory? Oleg Nesterov <oleg@redhat.com> - 2015-09-22 16:50 +0200
                Re: can't oom-kill zap the victim's memory? David Rientjes <rientjes@google.com> - 2015-09-22 01:50 +0200
            Re: can't oom-kill zap the victim's memory? Linus Torvalds <torvalds@linux-foundation.org> - 2015-09-21 19:00 +0200
    Re: can't oom-kill zap the victim's memory? Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2015-09-20 17:00 +0200
      Re: can't oom-kill zap the victim's memory? Oleg Nesterov <oleg@redhat.com> - 2015-09-20 17:00 +0200

csiph-web