On Fri, 4 May 2007, Peter Zijlstra wrote:

quoted text
> Page allocation rank is a scalar quantity connecting ALLOC_ and gfp flags which
> represents how deep we had to reach into our reserves when allocating a page. 
> Rank 0 is the deepest we can reach (ALLOC_NO_WATERMARK) and 16 is the most 
> shallow allocation possible (ALLOC_WMARK_HIGH).
> 
> When the slab space is grown the rank of the page allocation is stored. For
> each slab allocation we test the given gfp flags against this rank. Thereby
> asking the question: would these flags have allowed the slab to grow.
> 
> If not so, we need to test the current situation. This is done by forcing the
> growth of the slab space. (Just testing the free page limits will not work due
> to direct reclaim) Failing this we need to fail the slab allocation.

This implies that an allocation at time t2 must be aware of the result of 
an allocation at time t1. It assumes a linear ordering of allocations that 
is not possible on large systems. Ordering of events is a very expensive 
endeavor in particular on NUMA systems given the potentially large 
latencies between various portions of the system.

Maybe you need to restrict the ordering per cpu or per node? Per zone? 

Then we would need to store the ranks somewhere which raises scalability 
issues if these are global.


-
unsubscribe notice
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/