lkml.org 
[lkml]   [2000]   [Aug]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.691 / U:0.668 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site