Virtual memory is one of the most important subsystems of any modern operating system. Virtual memory is deeply intertwined with user processes, protection between processes and protection of the kernel from user processes, efficient shared memory, communication with IO (DMA, etc.), paging, swapping, and countless other systems. Understanding the VM subsystem greatly helps understanding how all other parts of the kernel work and interact. Because of this "Understanding the Linux Virtual Memory Manager" is a great guide in better understanding and working with the entire kernel.
Post a Comment
... if not for too many commas.
Can, you're only a sophomore? I'm impressed :-)
As a note for people interresting in VM, the NetBSD paper
about UVM is great reading.
Design and Implementation of UVM:
http://www.ccrc.wustl.edu/pub/chuck/psgz/diss.ps.gz
I was hopping for an "Understanding the Linux Virtual Memory Manager" article. Guess I should have read the title more closely eh? 
Still, excellent review.
Let me see if I've got this Virtual Memory thing straight...
It used to be that the computer copied data from disk to memory, then worked on it, then copied it back to disk again.
Then the data got really big and wouldn't all fit in memory anymore. But the computer still wanted to think it was working in memory.
So now the computer copies data from disk via memory to somewhere else on disk (which it pretends is memory), then copys the bits it needs to works on from the somewhere else on disk to memory, then works on them, then copies those bits back from memory to the somewhere else on disk, then finally copies them back from the somewhere else on disk via memory to the place on disk they were originally.
Sounds like a game of musical bit-buckets.
Anyway, 640KiB ought to be enough for anyone.
--
James G.
Well, virtual memory allows you to do what you've said. But VM is much more. It's about presenting virtual memory to appliations. That means applications sees its own address space, and is not to buther with the code/data of other processes or the kernel. i.e. it offers protection. All this is usualy done by an mmu, which must be presented with registers and tables for mapping a memory address on to physical memory,
and that's the hard part, maintaining all these mappings/tables in an efficient way, for all diffent kinds
of usage.
Read the
http://www.ccrc.wustl.edu/pub/chuck/psgz/diss.ps.gz as mentioned above, it offers insight.
it offer
"of any modern operating system"
*cough*
appearantly the writer never heard of DEC's uh Digital uh Compaq uhm HP's Virtual Memory System operating system.
as if virtual memory is some kind of new idea.
the great thing about linux is that it is always in a testing/experimental phase
VMS is a modern operating system. It has only been around since 1979.
So now the computer copies data from disk via memory to somewhere else on disk (which it pretends is memory), then copys the bits it needs to works on from the somewhere else on disk to memory, then works on them, then copies those bits back from memory to the somewhere else on disk, then finally copies them back from the somewhere else on disk via memory to the place on disk they were originally.
No, in modern VMs, that's not how it works. When you mmap() a file, nothing is loaded into memory. When you touch a page in that mapping, the appropriate data is brought in from disk and put into memory (into the unified VM cache). When memory runs tight, pages from the file that haven't been used in awhile are flushed back to the *same* file. So there is only one location in memory and one location on disk. These days, most VMs do this for *all* file I/O, not just for mmap()'ed regions. When you read 10 bytes from the middle of the file, the whole page is brought in and put into the buffer cache, just as if you'd mmap()'ed it. When you access that region again, the kernel just memcpy()'s the data into the buffer cache. As memory needs to be reused (or the file is closed) those pages are flushed back to the file.
since i inserted LOTS of RAM in this compoooooter 768 (3 256 sticks of DDR) now swap is allways on 0 and never used, it is still there just to keep my computer happy...
I have heard of VMS, and read the original paper describing the VMS VM architecture. Most of the common practices in VM systems actually originated there (e.g. not mapping anything to the first page, and segfaulting when somebody dereferences a null-pointer). What I meant was that in any "modern" operating system, VM is sure to play an important role, sorry about the confusion.
Thanks for all the feedback on the article everyone!