On Wed, Aug 22, 2007 at 10:03:45PM +0200, Peter Zijlstra wrote: > Its not extreme, not even rare, and its handled now. Its what > PF_MEMALLOC is for.
Agreed. This is the whole point, either you limit the max amount of anon memory, slab, alloc_pages a driver can do or you reserve a pool. Guess what? In practice limiting the max ram a driver can eat in alloc_pages, at the same time while limting the max amount of pages that can be anon ram, etc..etc.. is called "reserving a pool of freepages for PF_MEMALLOC". Now in theory we could try a may_writepage=0 second reclaim pass before using the PF_MEMALLOC pool but would that make any difference other than being slower? We can argue what should be done first but the PF_MEMALLOC pool isn't likely to go away with this patch... only way to make it go away is to have every subsystem including tcp incoming to have mempools for everything which is too complicated to implement so we've to live the imperfect world that just works good enough. This logic of falling back in a may_writepage=0 pass will make things a bit more reliable but certainly not perfect and it doesn't obsolete the need of the current code IMHO. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
