Re: anon_vma RFC2

Linus Torvalds
2004-03-12T18:22:10Z

On Fri, 12 Mar 2004, Rik van Riel wrote:
>
> I am suggesting a pointer from the mm_struct to a
> struct address_space ...

[ deleted ]

> Then on mremap you only need to adjust the start and
> end offsets inside the VMAs, not the page->index ...

One fundamental problem I see, maybe you can explain it to me...

- You need a _unique_ page->index start for each VMA, since each
anonymous page needs to have a unique index. Right?
- You can use the virtual address as that unique page index start
- when you mremap() an area, you leave the start indexes the same, so
that you can find the original pages (and create new ones in the old
mapping) by just searching the vma's, not by actually looking at the
page tables.
- HOWEVER, after a mremap(), when you now create a new vma (or expand an
old one) into the previously used page index area, you're now screwed.
How are you going to generate unique page indexes in this new area
without re-using the indexes that you allocated in the old (moved)
area?

I think your approach could work (reverse map by having separate address
spaces for unrelated processes), but I don't see any good "page->index"
allocation scheme that is implementable.

The "unique" page->index thing wouldn't need to have to have anything to
do with the virtual address (indeed, after a mremap it clearly cannot have
anything to do with that), but the thing is, you'd need to be able to
cover the virtual address space with whatever numbers you choose.

You'd want to allocate contiguous indexes within one "vma", since the
whole point would be to be able to try to quickly find the vma (and thus
the page) that contains one particular page, but there are no range
allocators that I can think of that allow growing the VMA after allocation
(needed for vma merging on mmap and brk()) and still keep the range of
indexes down to reasonable numbers.

Or did I totally mis-understand what you were proposing?

Linus