Re: RFC: design for new VM

[Matthew Dillon <dillon@apollo.backplane.com>]

:>     (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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/