Re: [patch] SLQB slab allocator

Zhang, Yanmin
2009-02-03T01:34:35Z

On Mon, 2009-02-02 at 10:00 -0500, Christoph Lameter wrote:
> On Mon, 2 Feb 2009, Pekka Enberg wrote:
>
> > Hi Yanmin,
> >
> > On Mon, 2009-02-02 at 11:38 +0800, Zhang, Yanmin wrote:
> > > Can we add a checking about free memory page number/percentage in function
> > > allocate_slab that we can bypass the first try of alloc_pages when memory
> > > is hungry?
> >
> > If the check isn't too expensive, I don't any reason not to. How would
> > you go about checking how much free pages there are, though? Is there
> > something in the page allocator that we can use for this?
>
> If the free memory is low then reclaim needs to be run to increase the
> free memory.
I think reclaim did start often with Hugh's case. There would be no swap if not.

> Falling back immediately incurs the overhead of going through
> the order 0 queues.
The falling back is temporal. Later on when there is enough free pages available,
new slab allocations go back to higher order automatically. This is to save the first
high-order allocation try because it often fails if memory is hungry.