Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Skip to content
Commit 3f5db3a0 authored by Douglas Anderson's avatar Douglas Anderson Committed by Dyneteve
Browse files

CHROMIUM: DROP: mm/oom_kill: Don't kill a subthread in our place if we still have mm



DROP THIS PATCH ON REBASE.

It is part of a patch series that attempts to solve similar problems
to the OOM reaper upstream.  NOTE that the OOM reaper patches weren't
backported because mm patches in general are fairly intertwined and
picking the OOM reaper without an mm expert and lots of careful
testing could cause new mysterious problems.

Compared to the OOM reaper, this patch series:
+ Is simpler to reason about.
+ Is not very intertwined to the rest of the system.
+ Can be fairly easily reasoned about to see that it should do no
  harm, even if it doesn't fix every problem.
- Can more easily get into the state where all memory reserves are
  gone, since it allows more than one task to be in "MEMDIE".
- Doesn't free memory as quickly.  The reaper kills anonymous /
  swapped memory even before the doomed task exits.
- Contains the magic "100 ms" heuristic, which is non-ideal.

---

In the function find_lock_task_mm() the stated purpose is to find a
subthread in the case that the original task no longer has an "->mm".

Implied in the description is that we should pick the original process
"p" if it still has "->mm" and we should only pick a subthread if
needed.  However, that's not what happens with the current
implementation.  Let's change the code to explicitly make sure that we
return the original process "p" if it has a valid "->mm".

Why do we care?  A future patch will improve the OOM killer to
sometimes allow more than one OOM victim to exist at once.  If we do
that without making find_lock_task_mm() prefer the original process
then we can get into this loop:
1. Pick a process as a victim.
2. Don't kill the chosen process, but instead kill some other task
   that (perhaps) has already been previously marked as a victim.
3. Go back to step #1 and pick the same process as a victim (since it
   wasn't actually killed before).

Even without the future patch, though, it still makes sense to pick
the original process if possible.

BUG=chromium:706048, chromium:702707
TEST=With whole series, eating memory doesn't hang system

Change-Id: I3b59bbff74bd5fed1fa7790dd9696e29030fba02
Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/465473
parent 7ccfc044
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment