Linux 2.4 VM Documentation

popoutman writes "Mel Gorman has announced the availability of a guide to the 2.4 kernel VM including a walkthrough of the VM code. Anyone interested in obtaining a solid understanding of the Linux 2.4 VM will certainly want to take a look at this documentation. Mel says that the effort is at least several weeks from being finished, but that he's releasing it now with the hopes of getting feedback to be sure he's on the right track. He also notes that the 2.5 VM is still too much of a moving target for him to document it just yet." See also a Kerneltrap story.

Comments

Re:Here's a tip for the author.

[iggymanz]

heh, it can stand for a few things in the realm of computers:
1. virtual memory (using secondary storage to allow the program to address more memory locations than there is in physical RAM)
2. virtual machine (a machine implemented in software on a real machine, which *could* have different opcodes, or the same ones as the real machine)
3. VM - the operating system by IBM which allows one of their mainframes to act like many (stands for virtual machine)

( Also, there's the VM in VMS, the DEC Vax and Alpha operating system, which stands for VIrtual Memory as in #1)

Re:VM: Does it really matter?

[GGardner]

I've always wondered why, in today's world of gigabytes of memory in personal computers, why such a big deal is made about virtual memory..

This is a good question -- there are several features the VM system allows for in addition to overcommitting physical memory. If your system has enough memory to run with no swap/paging space set up, the VM system still provides these features without ever paging or swapping out memory.

The first is demand paging. That is, only those pages of an executable that are needed are brought into memory, and on-demand. Yes, this saves memory, but more importantly, it makes program startup much faster. Without demand paging, the whole program would need to be brought into memory at startup. Nowadays, when disks are much slower relative to CPUs, than they used to be, this makes a big difference, especially in the Unix shell-pipeline style of programming, where you run many different short-lived programs.

Secondly, the VM system allows for shared memory segments between processes. This allows for shared memory, threads and shared libraries.

Finally, the VM system implements caching of the file system, which we all know and love as a good use for all the memory we stuff into our machines now.

Documentation and uncommunicative maintainer

[FeatureBug]

Documenting the VM is a good idea. I hope it is accepted into the /Documentation directory in 2.4.x kernel tarballs but I'm not sure whether you'd get a reply from the maintainer, Marcelo Tosatti. I sent him a carefully written email in August 2002 documenting an invalid config in 2.4.19 which causes the build process to fail. It was disappointing he never responded and apparently did not fix the bug which is still present in 2.4.20 and more recent patches.

Re:VM: Does it really matter?

[heh2k]

VM does NOT mean just paging/swapping. that is a small part of it. mac os and windows users constantly misuse the term. the vm does demand paging, copy-on-write, file/page cache, buffer cache, shared mem, mmapped files, and more. the most important of which is protection.

Re:VM: Does it really matter?

[Pseudonym]

I've always wondered why, in today's world of gigabytes of memory in personal computers, why such a big deal is made about virtual memory.

Because it's important. :-)

Some people think that virtual memory means paging to secondary memory, such as disk. It doesn't. Virtual memory systems can support this, but many OSes (e.g. QNX) support virtual memory with no disk paging. (OK, QNX does support disk paging, but only as an afterthought, so that QNX can be self-compiled. GCC takes a lot of memory.)

Virtual memory provides a virtual address space for each process. The benefits include:

• The system can avoid memory fragmentation because contiguous virtual pages do not need to be contiguous in physical memory.
• Processes don't step on each others' address spaces.
• Separate instances of the same program can share program text space and shared libraries.
• Different processes can use the same addresses for different purposes.
• Processes can share memory between each other in a controlled manner (for example, one process may have read-only access to some region, or memory can be shared between a parent and child process via a read-only or copy-on-write mechanism).
• Processes on different physical machines can share memory. (This can be done using the standard Unix interface. No extra kernel support is required.)
• Processes can view files as memory (e.g. using mmap), reading in only as much of the file as is necessary.
• Processes can allocate large regions of memory and only have the amount of those regions which they actually use backed up by physical memory (whether that is primary or secondary memory).
• The OS has a lot more freedom in how to lay out a process in physical memory to optimise cache usage.

This is just off the top of my head.