On Fri, 4 May 2007, Peter Zijlstra wrote:
> 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.
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
