Date: Wed, 26 Apr 2000 16:23:53 +0100
From: "Stephen C. Tweedie" <sct@redhat.com>
> Instead of talk, I'll show some code :-) The following is the
> anon layer I implemented for 2.3.x in my hacks.
OK --- I'm assuming you allow all of these address spaces to act as
swapper address spaces for the purpose of the swap cache?
Essentially, this is how it works yes.
This looks good, do you have the rest of the VM changes in a usable
(testable) state?
No, this is why I haven't posted the complete patch for general
consumption. It's in an "almost works" state, very dangerous,
and I don't even try leaving single user mode when I'm testing
it :-)))
On fork(), I assume you just leave multiple vmas attached to the
same address space? With things like mprotect, you'll still have a
list of vmas to search for in this design, I'd think.
At fork, the code which copies the address space just calls
"anon_dup()" for non-NULL vma->vm_anon, to clone the anon_area in the
child's VMA. anon_dup adds a new VMA to the mapping->i_mmap list and
bumps the anon_area reference count.
Actually, come to think of it, the anon_area reference count is
superfluous, because anon->mapping.i_mmap being NULL is equivalent to
the count going to zero. Superb, I can just kill that special
anon_area structure and use "struct address_space *vm_anon;" in the
vm_area_struct.
I'll try to clean up and stabilize my changes and post a patch
in the next few days.
Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 30 2000 - 21:00:11 EST