Messages in this thread | | | Date | Wed, 28 Aug 2002 14:58:20 -0700 | From | Andrew Morton <> | Subject | Re: [patch] adjustments to dirty memory thresholds |
| |
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |