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.
Somewhere in your document, you ought to explain what "VM" stands for. That goes for the poster as well.
Not to sound like a bitch; but if any you want to understand the concept of a good VM, you should read this which is a proven VM, and has been proven vastly superior to the new Linux VM(s).
If I were to spend a lot of time integrating a JVM into the kernal, would it be useful?
Kind of like FreeBSD did, fast JAVA under linux would be awesome.
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.
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
I'm no expert on Linux/Open Source, this is purely my curiosity at work. But it seems like many of the smallest projects, or those with large teams don't get documentation well after release. Or this is a misconception of mine?
I'm a little segfault, short and stout.
ooo kernel wapner ... need to read book....
We design aned document things first, work out the bugs in the high level design and then code.
Well maybe not all the time and with serveral itterations, but I only manage your credit raiting, not you kernel VM.
thank God the internet isn't a human right.
...that virtual memory works because of small, magical faeries and gnomes.
/syle
Congratulations to Mel Gorman for actually managing to get down to this low a level and still explain it sensibly.
5 5 (kerneltrap article)
n derstand.pdfu nderstand/u nderstand.txtThe second part is a code commentary which is literally a guided tourthrough the code. It is intended to help decipher the more crypticsections as well as identify the code patterns that are prevalent throughthe code. I decided to have the code separate from the first document asmaintaining the code in the document would be too painfulCode Commentary on the Linux Virtual Memory Managero de.pdfc odec ode.txt
Here are the links for interested readers:
http://www.kerneltrap.com/node.php?id=5
Actual documentation:
The documentation comes in two parts. The first is "Understanding theLinux Virtual Memory Manager" and it does pretty much as described. It isavailable in three formats, PDF, HTML and plain text.Understanding the Linux Virtual Memory Manager
PDF: http://www.csn.ul.ie/~mel/projects/vm/guide/pdf/u
HTML: http://www.csn.ul.ie/~mel/projects/vm/guide/html/
Text: http://www.csn.ul.ie/~mel/projects/vm/guide/text/
PDF: http://www.csn.ul.ie/~mel/projects/vm/guide/pdf/c
HTML: http://www.csn.ul.ie/~mel/projects/vm/guide/html/
Text: http://www.csn.ul.ie/~mel/projects/vm/guide/text/
This is great, however, where's the internals documentation for other subsystems of the kernel? People need documentation for JFS, ReiserFS, and other large systems. We'd see more of these in other kernels.
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..
I'm not trying to troll, and maybe someone can explain this to me, but as far as I know, VM is used when a computer runs out of RAM. You take some of what's in the RAM and toss it on to the hard drive. When you need it again, you reload it back into RAM and use it.
I've got 1.5GB of RAM in the box I'm typing this on, and the only reason I don't have more is that I have no use for it.
At my work, we've got some systems that can eat up 2GB of RAM, but we just put 4GB in the box and don't worry about it. We've found that if we let anything touch VM it slows things down way too much.
Anyways, I was hoping someone could enlighten me as to why VM has been such a big deal recently.
> 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 the "today's world" you describe is limited to the affluent portion of computer users/buyers. Many, many many computers exist in non-affluent parts of the real world that have 32-64Mb of RAM, and virtual memory is useful there. These machines are not ignored by the various Open Source OSs, they're deliberately targeted as being ideal platforms - still useful and usable despite being "obsolete" by Microsoft/Intel standards of What A Computer Should Have To Be Useful.
Because "slows things way down" is a damn sight better than "crashes applications and/or the system", especially on multiuser systems where there are certainly spikes of activity.
This is a known troll. Mod's: please check this user's other posts and moderate accordingly.
It's the other way round.
The real problem is "release early (without documentation)" rule.
Two words: Graphic arts. I edit reproductions of oil paintings, and some of my image files are upwards of a gigabyte themselves (before layers), so I imagine my undo buffer plus whatever GIMP needs to run whatever filter it's running can take up quite the hefty chunk of memory... and let's not even start on the amount of RAM it takes to hold a full-length feature film at high resolution in memory *uncompressed*.
Surreal_streaker is right this is a TROLL!
It's not the size of your .sig that matters, it's how you use it.
Uh -- that's a joke, right? Can't really tell... .ie as in Ireland, y'know, one of the many other English-Speaking countries out there... like, say, England?
It's
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.
Ireland boss....
Right here
I'm not a prophet or a stone-age man,
I'm just a mortal with potential of a super man.
-- Jack
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.
Why oil price increase equals economic trouble (Score: Interesti
Good point -- this is such a given on Unix systems that I didn't word it very well. What I should have said is that it enforces memory separation and protection between most memory segments and most processes, and allows for sharing of segments when explicitly setup. This is perhaps the most important thing the VM system does.
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.
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..
three basic reasons
1. resource virtualization
2. information isolation
3. fault isolation
We have a 3 systems (unix/not linux) each with 16G of RAM, 6TB of fiber attached SAN storage. When doing a sql query, the rdbms likes to cache indicies in RAM (real or perceived). If the dba team does not have a handle on what data needs to be pinned in RAM and what not, then VM becomes very popular and important. Unless you have data that will never change and an audience that will never make any different choices, then this predicting is a crap-shoot at best.
When to start chucking things off into paging space ? What stuff to chuck first ? File accesses ? Computational memory ? Processes ? Which processes go first ? Who's processes are more important ? Can the VM system be tuned without a reboot ? I have really been keeping my eye on these discussions for these reasons.
..but is it English speaking by choice? Check this out.
didn't you mean BSD/FreeBSD ?
V2_OS has had plenty of documentation for a long time, but no one to code it. It might be an exception among the Open Source projects, though.
Where the heck is .ie? He has surprisingly good English for someone who wasn't born in the US.
Here you go fellows, an excellent example of the [hopefully minority] view that America is the center of the universe.
Virtual Machine --- Not Virtual Memory.
VM does NOT mean just paging/swapping. that is a small part of it. mac os and windows users constantly misuse the term.
In all fairness, if under the old MacOS you booted with "virtual memory" off then virtual memory (in the correct sense) really was disabled.
If you are asking this question, it really means you have not worked on systems that do not have virtual memory, like DOS.
Virtual Memory means virtualizing a process's access to memory such that the memory addresses it accesses isn't necessarily the same physical memory address. It allows for complete memory separation between processes, which offers a vast amount of protection so that processes can't crash other processes.
The only alternative to Virtual Memory is to use actual physical memory addresses. This was exactly the case with DOS. In DOS you would have to manage memory and make sure your process (it's single-threaded... remember?!?) didn't overwrite memory that it didn't own. Everything in memory could be accessed from every single process.
With virtual memory, two processes could access memory location 0x1000000 and it would map to different physical memory addresses. In fact, the OS will give each process a full memory address range that is completely usuable by the process without any fear of stepping over someone else's memory. This effectively separates processes and prevents a hell of a lot of corruption because of memory bugs in programs.
This really simplifies programming because whenever we get a memory address from malloc, we don't have to do anything about making sure we don't step over someone else's memory information.
What you are in fact talking about is paging, the act of having a backing store of information on hard drive. This allows you to keep track of more memory than you physically have, by swapping memory back and forth from physical memory to a hard drive. Any unused memory would be paged to disk.
Yes, today you can have gigabytes of memory, and when running Mozilla, boy you really don't need virtual memory.
But what about 10 years from now, when Microsoft Office takes up 50 GB of hard drive space, and 16 GB of memory?
Virtual memory is a way of abstracting memory use on a per process basis, and it's inclusion in most modern operating systems is one of the reasons why things are relatively stable these days, compared to the old DOS days, anyway.
I did a lot of research on VMs about a year ago, and while the different VM systems out there really are interesting they're all kind of limited by the whole "page-level protection" model we've stuck with since the '70s. There are a lot of clever algorithms in the FreeBSD and 2.4 VMs to deal with high load and paging, but the core VM stuff (mapping memory, protection, sharing etc) is largely the same, and is limited by the MMU capabilities of current CPUs. All CPUs basically seperate processes into unique memory contexts, and map (using some sort of page table or reverse page table) physical memory pages of fixed size into the contexts. This solution is sub-optimal for object oriented systems with large scale sharing (the page tables get unweildy, and certain secondary structures, like reverse maps*, grow out of control). What I'd like to see is something new, just for the hell of it being new.
Here's what I'm thinking. Ditch pages and memory contexts entirely. Instead, divy up a 64-bit virtual address space among individual processes, say 48 bits apiece. If a process wants to access memory outside it's 48-bits, it would need to access it through special pointers (which, thanks to a tagged-RAM architecture) could written to by the OS (allowing the OS to define its own protection and sharing mechanisms). Does anybody know of any existing systems that work even vaguely like this? Or of a different MMU architecture at all? I was hoping that AMD might at least include software TLB management, because there is some nifty stuff you can do with that, but it looks like Hammer will use the same VM mechanism that came out with the 386!
A deep unwavering belief is a sure sign you're missing something...
English good as am beatnick useless Americaner slave in corner. Feednick good laces and shoe, da?
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:
This is just off the top of my head.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Because VM is not just used for swap. It's also used for memory protection, buffer caching, shared libraries, demand paging, and dozens of other performance improvements.
2.1.2 Browsing the Code
Generally, related operations are clustered together in the same file and there is not much copulation between modules.
I hope the discovery channel will do a special on copulating modules some day. I've seen module coupling but no copulation yet.
I truly think this should be modded as "Insightful", it's quite true in my experience.
The cure that I use for this is to read the code comments and subscribe to the mailing lists.
C|N>K
5 root 9 0 0 0 0 Z 0.0 0.0 0:18 kswapd
...going back at least through 2.2 kernels and it still happens with 2.4.18 (not the latest, but no real reason for me to build a new kernel unless it solves this). I've never read a thread on this that arrives at a solution or even a description of what is going on. I first encountered it when I went from Mandrake 8 (2.4.8 kernel) to 8.1 (2.4.18).
My kswapd went zombie after ~18days uptime; it had gone zombie after about 70 days prior to that reboot. I've found references to this occurance
Fortunately, I have plenty ram and this doesn't seem to otherwise affect anything.
While you, like us, have a Gbyte or more on your desktop system, most of the servers I've seen have an order of magnitude less. The vast majority of our 40+ servers have 128 Mbytes or less. That's because the desktops are the cheap junk we replace every couple of years. This round, we're using Dells. On our servers, we buy quality so we can't afford to upgrade nearly as often. $3,500 IBM rack-mount servers + $500 redundant power supplies + $1,500 RAID controllers + $800 or much more worth of SCSI hard drivers + ECC RAM, etc, is expensive. Over half of our servers that run Linux have an uptime of over one year. It would be very costly to replace them with something else that reliable. So, like most places, our servers end-up on the trailing edge of technology. Also, the cost of replacing servers is very expensive. The downtime and the pain of moving software is costly. We swap-out desktops in about half a day, but it took us three months to trackdown all of the little problems when we upgraded our PostgreSQL server. Small differences are painful when you have about 400 different programs that access data on that one server. So while on your desktop you only have to worry about a few applications, when we upgrade one of our servers, many more applications and many more people (including customers directly, if it's a web server!) are affected. That's why most servers have less RAM than you think they would. You just can't afford upgrade them!
This is why Linux is so nice. It makes good use of the hardware so, in the case of our Sun servers, it has given us three years (so far) more use out of the same hardware. And, no we didn't have 1.5 Gbytes of RAM on those machines when we bought them five years ago.
Another benefit is sparse allocation. When memory is allocated, it's all mapped to a zero filled page and marked copy on write. That allows programs to allocate massive arrays that are expected to be primarily filled with zeros without actually requiring that much memory. When a value is writen, a new page is allocated and mapped into the virtual space.
If desired, a file can be mmaped into the array instead to provide a simple persistant storage.
IIRC, suspend to disk is (or at least can be) also accomplished through VM.
The VM also allows an x86 system to have more than 4GB of ram. No single process can have more than a total of 4G (counting the kernel space) but using PAE, more than a total of 4GB can be allocated to multiple processes through the VM.
Although Linux doesn't do this, some OSes completely replace the filesystem with a VM. All files and directories are objects and are demand paged.
"Instructors used too many TLAs without explaining what they mean".
TLA=Three Letter Acronym, BTW
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
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.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Another cool thing 'bout virtual mem, is you no longer have a prob with memory fragmentation, or on old MacOS's "Largest available block"
Abstract:
Memory Management Units (MMUs) are traditionally used by operating systems to implement disk-paged virtual memory. Some operating systems allow user programs to specify the protection level (inaccessible, readonly, read-write) of pages, and allow user programs to handle protection violations, but these mechanisms are not always robust, efficient, or well-matched to the needs of applications. We survey several user-level algorithms that make use of page-protection techniques, and analyze their common characteristics, in an attempt to answer the question, "What virtual-memory primitives should the operating system provide to user processes, and how well do today's operating systems provide them?"
Similar, but 4Gb space split into 32Mb chunks. The running process's 32Mb chunk is swapped into the bottom page, so every process thinks it runs in 0-32mb address space.
Java is a compiled language that produce bytecode for the Java platform and have nothing to do with perl, python or TCL ... !!!
t ml ).
The bytecode is translated using a VM into native assembler either at the fly (the interpreter) or asynchronously with a JIT engine.
There come a common mistake : "Java is interpreted" ! That's the reason 1/3 of the people still thing Java and JavaScript are the same thing.
The Linux kernel do have a module dedicated to Java bytecode translation, but it is dog slow compare to the modern JIT engines (Hotspot with exact GC for instance).
When people talk about Java they generally talk about the platform and not the language. Just because once compiled, the language do not care any mode (please also note, that you can build bytecode classes using alternative languages such as eiffel, basic for instance using appropriates compiler http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.h
VM is not just for paging, which is what happens when you run out of RAM. It's a level of indirection between a memory address and a RAM chip. That level of indirection allows you to do all kinds of cool things.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
This is all very true, and as Figure 1 clearly shows, the ISA memory hole still causes problems:
_ _ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ _
f jhasdfkhahsdfy90y08fy08aw3408g0nb0h0bh00bhf00f0abh 0a0hfh0gh0aifhsdhghkasdkkchxnvnlasdf0g8y00a8b908fd halnblldvbnxcv8b08df-0b8--a8dfganslenal34n,mfnbmnx lkbn0adfbn8a8m-d-bh-a-npsnk33nkknlaw34nlkkljlkajkb j-9cv-b90a9-c-9adf-9b9a-9-9n3nkaklnFUCK TACO FUCK TACO FUCK TACO al;skdjflkasjd0gyb08cbxh08bhlxkbhlk3halasjdhfjlhas ;dfh;jlasdfjhasgjhgjhgjhogjhjhkhjjhbnhkhjhnfjjhfjk jknjfkjgnfjkljnh jfjhfhjfjfhghjlkjjhjlasdhf;lllllhhhahhhfalsa230pa3 h8-hwpvjdfnadfbh08xc0yb80xaho;bj4fn aj3bjabj;b0xc8[0x8fbyaiobf3jlwbjlwsbjlfasdflab79xp c7aguj;xkcbvs0x8y0kjaasbkdbnkjbaxxvna0r-0s-0d--f TENTACLE RAPE jfda8sd0f0a8sdhf-8as-dg0a=[nxlkncvl;na08rgvh-a9psd g ahsld0aac-x9bxcbn CLAIM FAILED lkjasfdnogvobxcaaax-98xccccccanpigasasdgn;occ8-ax9 jdsagne4o3n------9napisdamdn;jlansld DEFAULT CATCH asl;idkn0s08a008sd8f0cchcxchhd0as0d-fa-j3nnl3knlax 0c-8jsalejnfas800dg-0afg-a8u93ha;kjhq;j123e;qmnseu dfh0agg089asd-9c-x xcuihlkhslbhmhblkhcx08c-0x-080bh3km,
*_g_o_a_t_s_e_x_*_g_o_a_t_s_e_x_*_g_o_a_t_s_e_x_*
g_______________________________________________g
o_/_____\_____________\____________/____\_______o
a|_______|_____________\__________|______|______a
t|_______`._____________|_________|_______:_____t
s`________|_____________|________\|_______|_____s
e_\_______|_/_______/__\\\___--___\\_______:____e
x__\______\/____--~~__________~--__|_\_____|____x
*___\______\_-~____________________~-_\____|____*
g____\______\_________.--------.______\|___|____g
o______\_____\______//_________(_(__>__\___|____o
a_______\___.__C____)_________(_(____>__|__/____a
t_______/\_|___C_____)/______\_(_____>__|_/_____t
s______/_/\|___C_____)___ISA_|__(___>___/__\____s
e_____|___(____C_____)\______/__//__/_/_____\___e
x_____|____\__|_____\\_________//_(__/_______|__x
*____|_\____\____)___`----___--'_____________|__*
g____|__\______________\_______/____________/_|_g
o___|______________/____|_____|__\____________|_o
a___|_____________|____/_______\__\___________|_a
t___|__________/_/____|_________|__\___________|t
s___|_________/_/______\__/\___/____|__________|s
e__|_________/_/________|____|_______|_________|e
x__|__________|_________|____|_______|_________|x
FIGURE 1
Why this has never been fixed is a mystery to me.
GSA PUBLIC KEY
asl;dfhlaskhdflkhasdflkasdhkflhasldfhjaskhdk
--- this comment is presented in WIDE SCREEN STEREO!!!