tree 1aca242b8cd9e8aa7d87e105587906cba63a4f13
parent 864ab1276f04f5ff8b593a3abb9d3ccf635d0832
author Avery Pennarun <apenwarr@gmail.com> 1365073232 -0400
committer Avery Pennarun <apenwarr@gmail.com> 1365125444 -0400

__alloc_pages_slowpath: Give up timeslice if under memory pressure.

If we aren't able to get any memory despite going through the slowpath once,
suspend the current process until later.  Previously, the kernel would just
call cond_resched() in a few places, but that doesn't work well if the
current task has realtime priority: it will prevent other critical tasks
like kswapd, nfsiod, or mtdblock## from running.  Those tasks, in turn,
might need to run in order to actually free up memory, which is what the
alloc_pages_slowpath() loop is waiting for in the first place.

This fix is probably not really ideal (it would slow down recovery in the
"lucky" cases where we manage to clear things up after a single time through
the loop).  But it seems to be relatively harmless because it's such a
rarely-used code path.  And it definitely beats hanging the whole kernel.

This condition triggered very frequently when the OOM killed kicked in, but
note that the OOM killer is not actually necessary to cause the problem.  It
could occur if the kernel ever freed up pages from a realtime process and
needed to swap them back in.

I added printk's to each case, and confirmed that neither of them shows up
(at least on a TV box) under normal conditions.

b/8522311 b/7885817

Change-Id: I335cbc5dd3bba2f9bc9d6bc2a955ebebfc025bdc