Messages in this thread | | | Date | Fri, 4 Aug 2000 16:51:54 -0700 (PDT) | From | Matthew Dillon <> | Subject | Re: RFC: design for new VM |
| |
:> (fork) deal. Physical segment sharing outside of clone is something :> Linux could use to, I don't think it does it either. It's not easy to :> do right. : :It's probably impossible to do right. Basically, if you do it, you do it :wrong. : :As far as I can tell, you basically screw yourself on the TLB and locking :if you ever try to implement this. And frankly I don't see how you could :avoid getting screwed. : :There are architecture-specific special cases, of course. On ia64, the :..
I spent a weekend a few months ago trying to implement page table sharing in FreeBSD -- and gave up, but it left me with the feeling that it should be possible to do without polluting the general VM architecture.
For IA32, what it comes down to is that the page table generated by any segment-aligned mmap() (segment == 4MB) made by two processes should be shareable, simply be sharing the page directory entry (and thus the physical page representing 4MB worth of mappings). This would be restricted to MAP_SHARED mappings with the same protections, but the two processes would not have to map the segments at the same VM address, they need only be segment-aligned.
This would be a transparent optimization wholely invisible to the process, something that would be optionally implemented in the machine-dependant part of the VM code (with general support in the machine-independant part for the concept). If the process did anything to create a mapping mismatch, such as call mprotect(), the shared page table would be split.
The problem being solved for FreeBSD is actually quite serious -- due to FreeBSD's tracking of individual page table entries, being able to share a page table would radically reduce the amount of tracking information required for any large shared areas (shared libraries, large shared file mappings, large sysv shared memory mappings). For linux the problem is relatively minor - linux would save considerable page table memory. Linux is still reasonably scaleable without the optimization while FreeBSD currently falls on its face for truely huge shared mappings (e.g. 300 processes all mapping a shared 1GB memory area, aka Oracle 8i). (Linux falls on its face for other reasons, mainly the fact that it maps all of physical memory into KVM in order to manage it).
I think the loss of MP locking for this situation is outweighed by the benefit of a huge reduction in page faults -- rather then see 300 processes each take a page fault on the same page, only the first process would and the pte would already be in place when the others got to it. When it comes right down to it, page faults on shared data sets are not really an issue for MP scaleability.
In anycase, this is a 'dream' for me for FreeBSD right now. It's a very difficult problem to solve.
-Matt
- 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/
| |