Slashdot Mirror
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.
Most low level coders are going to find this very useful and I for one, even though I use Gnu/FreeBSD (lower context switch latency and better pipelining performance when under heavy paging loads, etc), am certainly glad to see the Linux camp start to come around regarding the documentation issue.
Fred Brooks in "The Mythical Man Month" states that proper documentation should be given a 20% time slice of each project if you want to have a successful product and this is certainly THE one arena where Linux is lacking, stopping them from commercial success.
As a tip for best results I suggeest using the Extreme Documentation method when writing your docs, it's saved time on the order of Olog(n) for me and a proven time saving technique.
Warmest regards,
--Jack
Wagner LLC Consulting Co. - Getting it right the first time
Wow, those santa clauses who work for Linux keep giving, don't they? Long past December, and here we have the shiny gift of Linux 2.4 kernal VM documentation?
I'll tell ya, I was just about done with SCSI over IP: in theory and praxis and I needed something to read on the crapper. Well, this certainly fits the bill! Thanks to all the hard workers at Linux! Good luck on the Playstation 3!
(-1, Raw and Uncut is the only way to read)
Correct me if you think YOU are wrong...
/drinks small glass of whisky and passes out.
I think some of the purpose of having Virtual Memmory (VM) is to address the constraints of any given architecture's idle processes being in a state of inactivity and their data in the system's RAM is "swapped" unto a file on the harddrive for the system's RAM to be available to processes that are still active and will benefit from the performance all ans while the processes don't recognize any VM subsystem or may choose to interact with it and this is one crazy run-on sentance. So, what's the problem and why do they feel the need to re-design and re-implement Linux VM support? Maybe you should first understand the scope of the principle of VM: applications do not know it is happening. Then slowly appen to your implementation hooks that allow applications to reschedule the kernel's interaction with virtual memmory and you lost scope of the *purpose*.
That's how I implemented VM in one of my applications! The difference between kernel-based VM is the application is not built to recognize and interact with VM, it is just there as a condition. VM-enabled kernels ARE SUPPOSED TO RELEASE KERNEL INFORMATION that instead of having 2GB of system RAM 4GB is available: not that bullshit "2GB free swap available" stuff. Relying on applications to interact with kernel-based VM decides the portability of applications.
But I'm sure you already Gnu that.
...kernel VM documents YOU!