Re: RFC/POC Make Page Tables Relocatable

[Dave Hansen <haveblue@us.ibm.com>]

On Thu, 2007-10-25 at 11:16 -0400, Ross Biro wrote:
> 1) Add a separate meta-data allocation to the slab and slub allocator
> and allocate full pages through kmem_cache_alloc instead of get_page.
> The primary motivation of this is that we could shrink struct page by
> using kmem_cache_alloc to allocate whole pages and put the supported
> data in the meta_data area instead of struct page. 

The idea seems cool, but I think I'm missing a lot of your motivation
here.

First of all, which meta-data, exactly, is causing 'struct page' to be
larger than it could be?  Which meta-data can be moved?

> 2) Add support for relocating memory allocated via kmem_cache_alloc.
> When a cache is created, optional relocation information can be
> provided.  If a relocation function is provided, caches can be
> defragmented and overall memory consumption can be reduced.

We may truly need this some day, but I'm not sure we need it for
pagetables.  If I were a stupid, naive kernel developer and I wanted to
get a pte page back, I might simply hold the page table lock, walk the
pagetables to the pmd, lock and invalidate the pmd, copy the pagetable
contents into a new page, update the pmd, and be on my merry way.  Why
doesn't this work?  I'm just fishing for a good explanation why we need
all the slab silliness.

I applaud you for posting early and posting often, but there is an
absolute ton of code in your patch.  For your subsequent postings, I'd
highly recommend trying to break it up in some logical ways.  Your 4
steps would be an excellent start.

You might also want to run checkpatch.pl on your patch.  It has some
style issues that also need to get worked out.

-- Dave

--
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>