Re: [patch] adjustments to dirty memory thresholds

[Andrew Morton]

William Lee Irwin III wrote:
> 
> ...
> I've already written the patch to address it, though of course, I can
> post those traces along with the patch once it's rediffed. (It's trivial
> though -- just a fresh GFP flag and a check for it before calling
> out_of_memory(), setting it in mempool_alloc(), and ignoring it in
> slab.c.) It requires several rounds of "un-throttling" to reproduce
> the OOM's, the nature of which I've outlined elsewhere.

That's a sane approach.  mempool_alloc() is designed for allocations
which "must" succeed if you wait long enough.

In fact it might make sense to only perform a single scan of the
LRU if __GFP_WLI is set, rather than the increasing priority thing.

But sigh.  Pointlessly scanning zillions of dirty pages and doing nothing
with them is dumb.  So much better to go for a FIFO snooze on a per-zone
waitqueue, be woken when some memory has been cleansed.  (That's effectively
what mempool does, but it's all private and different).

> One such trace is below, some of the others might require repeating the
> runs. It's actually a relatively deep call chain, I'd be worried about
> blowing the stack at this point as well.

Well it's presumably the GFP_NOIO which has killed it - we can't wait
on PG_writeback pages and we can't write out dirty pages.  Taking a
nap in mempool_alloc is appropriate.