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.

Here's a tip for the author.

[gpinzone]

Somewhere in your document, you ought to explain what "VM" stands for. That goes for the poster as well.

always nice to see some documentation

[mark_lybarger]

but this kernel has been out now since 04-Jan-2001. i know it took them a while to shake out the vm system, but the kernel is now stale. anybody who needs to know the internals of how vm works in the 2.4 kernel already knows. the rest of us just argue on /. about why there wasn't lots of testing done in past releases or about how you don't make big changes in a supposidly stable release series.

i'm sure those who need to know though are full aware of the vm workings of the 2.6 kernel (ibm, redhat, oracle, rik, google, etc).

Linux: the big player everyone likes to root for, but noone wants to put in the lineup.

Re:Here's a tip for the author.

[thodi]

People who don't know what it stands for would not want to read the document anyway, don't you think?

Re:VM: Does it really matter?

[Pseudonym]

If desired, a file can be mmaped into the array instead to provide a simple persistant storage.

Mmap is way, way more useful than that.

The key benefit of mmap is that on decent OSes (i.e. not NT/2000/XP), you get effectively get the buffer cache for the file mapped into your address space. Without mmap, you'd effectively have two copies of the file go through memory: one in the buffer cache and one in the application.

This is not so serious if your file is a sequentially-read stream, because the application won't hold much at a time. However, if it's a randomly accessed file with a large working set (e.g. in a database server), the win is huge.