On Wed, 16 May 2007, Peter Zijlstra wrote: > > Hmmm.. so we could simplify the scheme by storing the last rank > > somewheres. > > Not sure how that would help..
One does not have a way of determining the current processes priority? Just need to do an alloc? If we had the current processes "rank" then we could simply compare. If rank is okay give them the object. If not try to extend slab. If that succeeds clear the rank. If extending fails fail the alloc. There would be no need for a reserve slab. What worries me about this whole thing is 1. It is designed to fail an allocation rather than guarantee that all succeed. Is it not possible to figure out which processes are not essential and simply put them to sleep until the situation clear up? 2. It seems to be based on global ordering of allocations which is not possible given large systems and the relativistic constraints of physics. Ordering of events get more expensive the bigger the system is. How does this system work if you can just order events within a processor? Or within a node? Within a zone? 3. I do not see how this integrates with other allocation constraints: DMA constraints, cpuset constraints, memory node constraints, GFP_THISNODE, MEMALLOC, GFP_HIGH. - 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/