Re: RFC/POC Make Page Tables Relocatable

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

On Thu, 2007-10-25 at 14:44 -0400, Ross Biro wrote:
> On 10/25/07, Dave Hansen <haveblue@us.ibm.com> wrote:
> > > This would almost work, but to do it properly, you find you'll need
> > > some more locks and a couple of extra pointers and such.
> >
> > Could you be specific?
> 
> Well to go quickly from an arbitrary page that happens to be part of a
> page table to the appropriate mm to get a lock, I had to store a
> pointer to the mm.

Hold on a sec there.  You don't *have* to. :)

With the pagetable page you can go examine ptes.  From the ptes, you can
get the 'struct page' for the mapped page.  From there, you can get the
anon_vma and at least the list of mms that _could_ map the page.  You
get virtual addresses from the linear_page_index() or offset in the
mapping from page->index and vma->vm_pgoff and vm_start.  That should
make the search a bit more reasonable.

Slow, yes.  But, we're already talking about reclaim paths here.  

> Then I also needed to know where the particular
> page fit into the page table tree.  Once I had those, it turned out I
> needed a spinlock to protect them to deallocate the page with out
> racing against the relocation.  I think I could have used the ptl lock
> struct page, but I wasn't really clear on it when I started.
> 
> So I needed 2 pointers which I could have squeezed into struct page
> somewhere, but then what about when I needed a third or forth pointer
> to make something else work well?

I think you started out with the assumption that we needed out of page
metadata and then started adding more reasons that we needed it.  I
seriously doubt that you really and truly *NEED* four new fields in
'struct page'. :)

My guys says that this is way too complicated to be pursued in this
form.  But, don't listen to me.  You don't have to convince _me_.

If you want to pursue this, I'd concentrate on breaking your patch up in
to manageable pieces.  Don't forget diffstats at the top of your patch,
too.  If I were to start breaking this patch up, I'd probably start with
these things, but probably not in this order.  If you do it right,
you'll end up with even more pieces than this.

1. add support to slab for object relocation
2. add support to slab for object metadata
3. allocate pte pages from the slab (yet again)
4. add metadata for pagetable pages (this can be distinct from the other
   patches, and a simple implementation might just stick it in 'struct
   page' to make it easy to review at first)
5. add and use walk_page_table_*() functions
6. add need_flush tracking to the mm
7. add minimum base page size requirements to the slab
8. add relocation handles
9. your test module
10. rcu for freeing pagetables and tlb flushing
11. actual pagetable relocation code

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