[RFC][PATCH 0/3] big chunk memory allocator v2
Andi Kleen
andi.kleen at intel.com
Fri Oct 29 08:29:28 EDT 2010
On Fri, Oct 29, 2010 at 11:59:00AM +0100, KAMEZAWA Hiroyuki wrote:
> On Fri, 29 Oct 2010 12:31:54 +0200
> Andi Kleen <andi.kleen at intel.com> wrote:
>
> > > When I was posting CMA, it had been suggested to create a new migration type
> > > dedicated to contiguous allocations. I think I already did that and thanks to
> > > this new migration type we have (i) an area of memory that only accepts movable
> > > and reclaimable pages and
> >
> > Aka highmem next generation :-(
> >
>
> yes. But Nick's new shrink_slab() may be a new help even without
> new zone.
You would really need callbacks into lots of code. Christoph
used to have some patches for directed shrink of dcache/icache,
but they are currently not on the table.
I don't think Nick's patch does that, he simply optimizes the existing
shrinker (which in practice tends to not shrink a lot) to be a bit
less wasteful.
The coverage will never be 100% in any case. So you always have to
make a choice between movable or fully usable. That's essentially
highmem with most of its problems.
>
>
> > > (ii) is used only if all other (non-reserved) pages have
> > > been allocated.
> >
> > That will be near always the case after some uptime, as memory fills up
> > with caches. Unless you do early reclaim?
> >
>
> memory migration always do work with alloc_page() for getting migration target
> pages. So, memory will be reclaimed if filled by cache.
Was talking about that paragraph CMA, not your patch.
If I understand it correctly CMA wants to define
a new zone which is somehow similar to movable, but only sometimes used
when another zone is full (which is the usual state in normal
operation actually)
It was unclear to me how this was all supposed to work. At least
as described in the paragraph it cannot I think.
> About my patch, I may have to prealloc all required pages before start.
> But I didn't do that at this time.
preallocate when? I thought the whole point of the large memory allocator
was to not have to pre-allocate.
-Andi
More information about the linux-arm-kernel
mailing list