Re: Page allocator: Single Zone optimizations

[Christoph Lameter <clameter@sgi.com>]

On Fri, 27 Oct 2006, Andrew Morton wrote:

> Right.  We need zones for lots and lots of things.  This all comes back to
> my main point: the hardwired and magical DMA, DMA32, NORMAL and HIGHMEM
> zones don't cut it.  We'd be well-served by implementing the core MM as
> just "one or more zones".  The placement, sizing and *meaning* behind those
> zones is externally defined.

We (and I personally with the prezeroing patches) have been down 
this road several times and did not like what we saw. 

> That's all virtual machine stuff, where the "kernel"'s memory is virtual,
> not physical.

That is the case on most platforms x86_64, ia64. Kernel memory is movable
and the Virtual Iron guys have demonstrated how to do that without
additional zones.
> 
> > > Userspace allocations are reclaimable: pagecache, anonymous memory.  These
> > > happen to be allocated with __GFP_HIGHMEM set.
> > 
> > On certain platforms yes.
> 
> On _all_ platforms.  See GFP_HIGHUSER.

User space allocations are movable already via page migration. 

> > > So right now __GFP_HIGHMEM is an excellent hint telling the page allocator
> > > that it is safe to satisfy this request from removeable memory.

For that we would have to have a distinction of removable memory which 
wont be necessary if we use the existing mappings to move the physical
location while keeping the virtual addresses.

> I don't think there's any other (practical) way of implementing hot-unplug.

Of course there is. As soon as you have virtual mappings its fairly easy 
to do.

1. Migrate all what you can off the memory section that you want to
   free.

2. Use the page table to dynamically remap the leftover pages.

> But hot-unplug is just an example.  My main point here is that it is
> desirable that we get away from the up-to-four magical hard-wired zones in
> core MM.

We have been facing that decision repeatedly and it was pretty clear that 
there would be significant disadvantages.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>