+ mm-oom-remove-sleep-from-under-oom_lock.patch added to -mm tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The patch titled
     Subject: mm, oom: remove sleep from under oom_lock
has been added to the -mm tree.  Its filename is
     mm-oom-remove-sleep-from-under-oom_lock.patch

This patch should soon appear at
    http://ozlabs.org/~akpm/mmots/broken-out/mm-oom-remove-sleep-from-under-oom_lock.patch
and later at
    http://ozlabs.org/~akpm/mmotm/broken-out/mm-oom-remove-sleep-from-under-oom_lock.patch

Before you just go and hit "reply", please:
   a) Consider who else should be cc'ed
   b) Prefer to cc a suitable mailing list as well
   c) Ideally: find the original patch on the mailing list and do a
      reply-to-all to that, adding suitable additional cc's

*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***

The -mm tree is included into linux-next and is updated
there every 3-4 working days

------------------------------------------------------
From: Michal Hocko <mhocko@xxxxxxxx>
Subject: mm, oom: remove sleep from under oom_lock

Tetsuo has pointed out that since 27ae357fa82b ("mm, oom: fix concurrent
munlock and oom reaper unmap, v3") we have a strong synchronization
between the oom_killer and victim's exiting because both have to take the
oom_lock.  Therefore the original heuristic to sleep for a short time in
out_of_memory doesn't serve the original purpose.

Moreover Tetsuo has noticed that the short sleep can be more harmful than
actually useful.  Hammering the system with many processes can lead to a
starvation when the task holding the oom_lock can block for a long time
(minutes) and block any further progress because the oom_reaper depends on
the oom_lock as well.

Drop the short sleep from out_of_memory when we hold the lock.  Keep the
sleep when the trylock fails to throttle the concurrent OOM paths a bit. 
This should be solved in a more reasonable way (e.g.  sleep proportional
to the time spent in the active reclaiming etc.) but this is much more
complex thing to achieve.  This is a quick fixup to remove a stale code.

Link: http://lkml.kernel.org/r/20180709074706.30635-1-mhocko@xxxxxxxxxx
Signed-off-by: Michal Hocko <mhocko@xxxxxxxx>
Reported-by: Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx>
Cc: David Rientjes <rientjes@xxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---

 mm/oom_kill.c |    8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff -puN mm/oom_kill.c~mm-oom-remove-sleep-from-under-oom_lock mm/oom_kill.c
--- a/mm/oom_kill.c~mm-oom-remove-sleep-from-under-oom_lock
+++ a/mm/oom_kill.c
@@ -1121,15 +1121,9 @@ bool out_of_memory(struct oom_control *o
 		dump_header(oc, NULL);
 		panic("Out of memory and no killable processes...\n");
 	}
-	if (oc->chosen && oc->chosen != (void *)-1UL) {
+	if (oc->chosen && oc->chosen != (void *)-1UL)
 		oom_kill_process(oc, !is_memcg_oom(oc) ? "Out of memory" :
 				 "Memory cgroup out of memory");
-		/*
-		 * Give the killed process a good chance to exit before trying
-		 * to allocate memory again.
-		 */
-		schedule_timeout_killable(1);
-	}
 	return !!oc->chosen;
 }
 
_

Patches currently in -mm which might be from mhocko@xxxxxxxx are

memblock-do-not-complain-about-top-down-allocations-for-memory_hotremove.patch
mm-do-not-bug_on-on-incorrect-lenght-in-__mm_populate.patch
mm-drop-vm_bug_on-from-__get_free_pages.patch
memcg-oom-move-out_of_memory-back-to-the-charge-path.patch
mm-oom-remove-sleep-from-under-oom_lock.patch
mm-oom-docs-describe-the-cgroup-aware-oom-killer-fix-2.patch

--
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Kernel Archive]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]

  Powered by Linux