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

Groups > linux.kernel > #1227268 > unrolled thread

[PATCH] mm/oom_kill.c: don't kill TASK_UNINTERRUPTIBLE tasks

Back to article view | Back to linux.kernel

Contents

  [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

Page 4 of 4 — ← Prev page 1 2 3 [4]

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

Michal Hocko wrote:
> On Mon 28-09-15 15:24:06, David Rientjes wrote:
> > I agree that i_mutex seems to be one of the most common offenders.  
> > However, I'm not sure I understand why holding it while trying to allocate 
> > infinitely for an order-0 allocation is problematic wrt the proposed 
> > kthread. 
> 
> I didn't say it would be problematic. We are talking past each other
> here. All I wanted to say was that a separate kernel oom thread wouldn't
> _help_ with the lock dependencies.
> 
Oops. I misunderstood that you are skeptical about memory unmapping approach
due to lock dependency. But rather, you are skeptical about use of a dedicated
kernel thread for memory unmapping approach.

> > The kthread itself need only take mmap_sem for read.  If all 
> > threads sharing the mm with a victim have been SIGKILL'd, they should get 
> > TIF_MEMDIE set when reclaim fails and be able to allocate so that they can 
> > drop mmap_sem. 
> 
> which is the case if the direct oom context used trylock...
> So just to make it clear. I am not objecting a specialized oom kernel
> thread. It would work as well. I am just not convinced that it is really
> needed because the direct oom context can use trylock and do the same
> work directly.

Well, I think it depends on from where we call memory unmapping code.

The first candidate is oom_kill_process() because it is a location where
the mm struct to unmap is determined. But since select_bad_process()
aborts upon encountering a TIF_MEMDIE task, we will fail to call memory
unmapping code again if the first down_trylock(&mm->mmap_sem) attempt in
oom_kill_process() failed. (Here I assumed that we allow all OOM victims
to access memory reserves so that subsequent down_trylock(&mm->mmap_sem)
attempts could succeed.)

The second candidate is select_bad_process() because it is a location
where we can call memory unmapping code again upon encountering a
TIF_MEMDIE task.

The third candidate is caller of out_of_memory() because it is a location
where we can call memory unmapping code again even when the OOM victims
are blocked. (Our discussion seems to assume that TIF_MEMDIE tasks can
make forward progress and die. But since TIF_MEMDIE tasks might encounter
unkillable locks after returning from allocation (e.g.
http://lkml.kernel.org/r/201509290118.BCJ43256.tSFFFMOLHVOJOQ@I-love.SAKURA.ne.jp ),
it will be safer not to assume that out_of_memory() can be always called.
So, I thought that a dedicated kernel thread makes it easy to call memory
unmapping code periodically again and again.
--
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/

[toc] | [prev] | [next] | [standalone]

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

Oleg Nesterov wrote:
> Yes, yes, and I already tried to comment this part. 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.
> 
I imagined a dedicated kernel thread doing something like shown below.
(I don't know about mm->mmap management.)
mm->mmap_zapped corresponds to MMF_MEMDIE.
I think this kernel thread can be used for normal kill(pid, SIGKILL) cases.

----------
bool has_sigkill_task;
wait_queue_head_t kick_mm_zapper;

static void mm_zapper(void *unused)
{
	struct task_struct *g, *p;
	struct mm_struct *mm;

sleep:
	wait_event(kick_remover, has_sigkill_task);
	has_sigkill_task = false;
restart:
	rcu_read_lock();
	for_each_process_thread(g, p) {
		if (likely(!fatal_signal_pending(p)))
			continue;
		task_lock(p);
		mm = p->mm;
		if (mm && mm->mmap && !mm->mmap_zapped && down_read_trylock(&mm->mmap_sem)) {
			atomic_inc(&mm->mm_users);
			task_unlock(p);
			rcu_read_unlock();
			if (mm->mmap && !mm->mmap_zapped)
				zap_page_range(mm->mmap, 0, TASK_SIZE, NULL);
			mm->mmap_zapped = 1;
			up_read(&mm->mmap_sem);
			mmput(mm);
			cond_resched();
			goto restart;
		}
		task_unlock(p);
	}
	rcu_read_unlock();
	goto sleep;
}

kthread_run(mm_zapper, NULL, "mm_zapper");
----------
--
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/

[toc] | [prev] | [next] | [standalone]

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

On 09/22, Tetsuo Handa wrote:
>
> I imagined a dedicated kernel thread doing something like shown below.
> (I don't know about mm->mmap management.)
> mm->mmap_zapped corresponds to MMF_MEMDIE.

No, it doesn't, please see below.

> bool has_sigkill_task;
> wait_queue_head_t kick_mm_zapper;

OK, if this kthread is kicked by oom this makes more sense, but still
doesn't look right at least initially.

Let me repeat, I do think we need MMF_MEMDIE or something like it before
we do something more clever. And in fact I think this flag makes sense
regardless.

> static void mm_zapper(void *unused)
> {
> 	struct task_struct *g, *p;
> 	struct mm_struct *mm;
>
> sleep:
> 	wait_event(kick_remover, has_sigkill_task);
> 	has_sigkill_task = false;
> restart:
> 	rcu_read_lock();
> 	for_each_process_thread(g, p) {
> 		if (likely(!fatal_signal_pending(p)))
> 			continue;
> 		task_lock(p);
> 		mm = p->mm;
> 		if (mm && mm->mmap && !mm->mmap_zapped && down_read_trylock(&mm->mmap_sem)) {
                                       ^^^^^^^^^^^^^^^

We do not want mm->mmap_zapped, it can't work. We need mm->needs_zap
set by oom_kill_process() and cleared after zap_page_range().

Because otherwise we can not handle CLONE_VM correctly. Suppose that
an innocent process P does vfork() and the child is killed but not
exited yet. mm_zapper() can find the child, do zap_page_range(), and
surprise its alive parent P which uses the same ->mm.

And if we rely on MMF_MEMDIE or mm->needs_zap or whaveter then
for_each_process_thread() doesn't really make sense. And if we have
a single MMF_MEMDIE process (likely case) then the unconditional
_trylock is suboptimal.

Tetsuo, can't we do something simple which "obviously can't hurt at
least" and then discuss the potential improvements?

And yes, yes, the "Kill all user processes sharing victim->mm" logic
in oom_kill_process() doesn't 100% look right, at least wrt the change
we discuss.

Oleg.

--
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/

[toc] | [prev] | [next] | [standalone]

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

Oleg Nesterov wrote:
> On 09/22, Tetsuo Handa wrote:
> >
> > I imagined a dedicated kernel thread doing something like shown below.
> > (I don't know about mm->mmap management.)
> > mm->mmap_zapped corresponds to MMF_MEMDIE.
> 
> No, it doesn't, please see below.
> 
> > bool has_sigkill_task;
> > wait_queue_head_t kick_mm_zapper;
> 
> OK, if this kthread is kicked by oom this makes more sense, but still
> doesn't look right at least initially.

Yes, I meant this kthread is kicked upon sending SIGKILL. But I forgot that

> 
> Let me repeat, I do think we need MMF_MEMDIE or something like it before
> we do something more clever. And in fact I think this flag makes sense
> regardless.
> 
> > static void mm_zapper(void *unused)
> > {
> > 	struct task_struct *g, *p;
> > 	struct mm_struct *mm;
> >
> > sleep:
> > 	wait_event(kick_remover, has_sigkill_task);
> > 	has_sigkill_task = false;
> > restart:
> > 	rcu_read_lock();
> > 	for_each_process_thread(g, p) {
> > 		if (likely(!fatal_signal_pending(p)))
> > 			continue;
> > 		task_lock(p);
> > 		mm = p->mm;
> > 		if (mm && mm->mmap && !mm->mmap_zapped && down_read_trylock(&mm->mmap_sem)) {
>                                        ^^^^^^^^^^^^^^^
> 
> We do not want mm->mmap_zapped, it can't work. We need mm->needs_zap
> set by oom_kill_process() and cleared after zap_page_range().
> 
> Because otherwise we can not handle CLONE_VM correctly. Suppose that
> an innocent process P does vfork() and the child is killed but not
> exited yet. mm_zapper() can find the child, do zap_page_range(), and
> surprise its alive parent P which uses the same ->mm.

kill(P's-child, SIGKILL) does not kill P sharing the same ->mm.
Thus, mm_zapper() can be used for only OOM-kill case and
test_tsk_thread_flag(p, TIF_MEMDIE) should be used than
fatal_signal_pending(p).

> 
> And if we rely on MMF_MEMDIE or mm->needs_zap or whaveter then
> for_each_process_thread() doesn't really make sense. And if we have
> a single MMF_MEMDIE process (likely case) then the unconditional
> _trylock is suboptimal.

I guess the more likely case is that the OOM victim successfully exits
before mm_zapper() finds it.

I thought that a dedicated kernel thread which scans the task list can do
deferred zapping by automatically retrying (in a few seconds interval ?)
when down_read_trylock() failed. 

> 
> Tetsuo, can't we do something simple which "obviously can't hurt at
> least" and then discuss the potential improvements?

No problem. I can wait for your version.

> 
> And yes, yes, the "Kill all user processes sharing victim->mm" logic
> in oom_kill_process() doesn't 100% look right, at least wrt the change
> we discuss.

If we use test_tsk_thread_flag(p, TIF_MEMDIE), we will need to set
TIF_MEMDIE to the victim after sending SIGKILL to all processes sharing
the victim's mm. Well, the likely case that the OOM victim exits before
mm_zapper() finds it becomes not-so-likely case? Then, MMF_MEMDIE is
better than test_tsk_thread_flag(p, TIF_MEMDIE)...

> 
> Oleg.
--
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/

[toc] | [prev] | [next] | [standalone]

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

On 09/22, Tetsuo Handa wrote:
>
> Oleg Nesterov wrote:
> > On 09/22, Tetsuo Handa wrote:
> > > 	rcu_read_lock();
> > > 	for_each_process_thread(g, p) {
> > > 		if (likely(!fatal_signal_pending(p)))
> > > 			continue;
> > > 		task_lock(p);
> > > 		mm = p->mm;
> > > 		if (mm && mm->mmap && !mm->mmap_zapped && down_read_trylock(&mm->mmap_sem)) {
> >                                        ^^^^^^^^^^^^^^^
> >
> > We do not want mm->mmap_zapped, it can't work. We need mm->needs_zap
> > set by oom_kill_process() and cleared after zap_page_range().
> >
> > Because otherwise we can not handle CLONE_VM correctly. Suppose that
> > an innocent process P does vfork() and the child is killed but not
> > exited yet. mm_zapper() can find the child, do zap_page_range(), and
> > surprise its alive parent P which uses the same ->mm.
>
> kill(P's-child, SIGKILL) does not kill P sharing the same ->mm.
> Thus, mm_zapper() can be used for only OOM-kill case

Yes, and only if we know for sure that all tasks which can use
this ->mm were killed.

> and
> test_tsk_thread_flag(p, TIF_MEMDIE) should be used than
> fatal_signal_pending(p).

No. For example, just look at mark_oom_victim() at the start of
out_of_memory().

> > Tetsuo, can't we do something simple which "obviously can't hurt at
> > least" and then discuss the potential improvements?
>
> No problem. I can wait for your version.

All I wanted to say is that this all is a bit more complicated than it
looks at first glance.

Oleg.

--
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/

[toc] | [prev] | [next] | [standalone]

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

On Mon, 21 Sep 2015, Oleg Nesterov wrote:

> 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, 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 agree with the direction and I don't think it would be too complex to 
have a dedicated kthread that is kicked when we queue an mm to do 
MADV_DONTNEED behavior, and have that happen only if a trylock in 
oom_kill_process() fails to do it itself for anonymous mappings.  We may 
have different opinions of simplicity.
--
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/

[toc] | [prev] | [next] | [standalone]

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

On Mon, Sep 21, 2015 at 6:44 AM, Oleg Nesterov <oleg@redhat.com> wrote:
>
> I must have missed something. I can't understand your and Michal's
> concerns.

Heh.  I looked at that patch, and apparently entirely missed the
queue_work() part of the whole patch, thinking it was a direct call.

So never mind.

                Linus
--
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/

[toc] | [prev] | [next] | [standalone]

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

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.
--
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/

[toc] | [prev] | [next] | [standalone]

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

On 09/20, Tetsuo Handa wrote:
>
> 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?

Yes.

> 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?).

I don't think so... but we might want to do this if (say) we are not going
to kill someone else because fatal_signal_pending(current).

> A dedicated kernel thread (not limited to OOM-kill purpose)
> scans for fatal_signal_pending() tasks and release that task's memory.

Perhaps a dedicated kernel thread makes sense (see other emails),
but I don't think it should scan the killed threads. oom-kill should
kict it.

Anyway, let me repeat there are a lot of details we might want to
discuss. But the initial changes should be simple as possible, imo.

Oleg.

--
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/

[toc] | [prev] | [standalone]

Page 4 of 4 — ← Prev page 1 2 3 [4]

Back to top | Article view | linux.kernel

csiph-web