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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/