Linus And Alan Settle On A New VM System 167
stylewagon writes: "ZDNet are reporting that Linus Torvalds and Alan Cox have finally agreed on which Virtual Memory manager to include in future kernel releases. Both have agreed to use the newer VM, written by Andrea Arcangeli, from kernel version 2.4.10 onwards. Read more in the article."
sensation seekers (Score:5, Informative)
I cite November 2nd: The great VM dispute really isn't. It went something along the lines of "Putting a new vm in 2.4.10 is crzy", "Probably it was but its done so lets make it work" and at 2.4.14pre8 "See it works" "Yep".
NUMA?! (Score:5, Informative)
It's previously been argued that Andrea's VM doesn't work with NUMA architectures, hence work should continue on Rik's 2.4.x design
Not a problem now, but it's one of the major aims of 2.5, according to Linus. Anyone know how they are going to square this circle?
Minor point (Score:5, Informative)
From the article: Torvalds is close to handing over the stable 2.4 kernel to Cox.
...and I thought that Marcelo Tosatti was going to maintain 2.4 [slashdot.org].
Re:NUMA?! (Score:4, Informative)
Re:This article is a joke... (Score:4, Informative)
Just in case somebody doesn't believe you, here's the proof [advogato.org].
Re:So what? (Score:4, Informative)
Rik van Riel on the Future of VM Work (Score:4, Informative)
http://www.osdn.com/conferences/kernel [osdn.com]
They have Real format in both 56K and 128K streams, Mpeg, and Mp3 of his speach. Looks interesting if you've got the bandwidth and the time.
virtual memory (Score:5, Informative)
Bear in mind, this is only the basic gist of what virtual memory is all about. This particlar subsystem will also handle memory paging (which is part of swapping out to disk), amongst other tasks.
Before you really get determined to start hacking the kernel tomorrow, I suggest you start with something a little more meager. You need to get some experience in computer arcitecture fundamentals, then really basic OS design. Read a few books. Learn Motorola or IA32 Assembly language. Learn to write some old DOS programs (a number of DOS emulators with free, open source DOS distros are available, so some searching) where you have to allocate every byte and word by hand, and not just say "Foo *f; f=new Foo();". Next, start to learn C and figure out what malloc() is all about. Then try coding a kernel module. This is obviously not an extensive road map, but computers and their operating systems are sophisticated. You can't really (unless you're someone like Cox or Torvalds) just dive right into systems programming and know what you're doing. It may take years of experience before you start to tinker with code in the kernel and actually write something that works.
Re:This article is a joke... (Score:3, Informative)
Just for the record (I've pointed this out elsewhere), SuSE Inc. is a U.S. company... SuSE has done the general equivalent of incorporating in several countries, including the U.S. SuSE Inc. is, in fact, in Oakland as the article reports.
Of course, it might not be SuSE's U.S. corporation that's involved here, but that's a completely different possible source of inaccuracy. ;)
My biggest problem with Linux was the old VM. (Score:5, Informative)
Why do we use such small systems? Because we want them to perform under extream load when placed on larger systems. Its smart really, its easy to benchmark a few functions on a pentium 75, than a 2 ghz pentium. If your application doesn't run peppy with one usuer on a pentirum 75, it sure as hell won't support 1000 users on 2 ghz pentium.
Thats why we have used FreeBSD for all this time, in FreeBSD the VM manager is perfect, and isnt' even slated for upgrade in the near future due to the fact it works like it should. If you are using telnet on a FreeBSD machine, and _one_ applications uses a ton of resources, that one application will run slow. But your telnet will continue on fine. Try putting 12 megs of RAM in your machine, than compiling PostgreSQL while using a telnet session. You won't even notice the compile on FreeBSD, but you will with Linux.
Funny enough, this also ties into the article earlier regarding why Linux isn't used for alot of large scale databases. Databases consume HUGE amounts of RAM and the OS under it has to be peppy about it. Linux in the past has been tuned for desktop/single user performance and not what those databases need. They need TONS of resources, and quick _CONSISTANT_ access to it.
That said, I am very happy to see them getting a better VM. Because my biggest problem with FreeBSD is its crappy java support, the most recent stable JDK it supports is 1.2.2. And thats in Linux emulation mode!
So if things work out, and Linux supports java well, and doesn' crap out when it runs out of resources. We will defiently switch to Linux, and life will be good!
Re:Details please (Score:3, Informative)
Rik's VM is considerred "smarter." It works harder to balance things out and keeps track of all kinds of info.
Andrea's is not very well documented.
Andrea's is simpler.
Andrea's uses "class zones" which are not good for NUMA. We want to have NUMA in 2.5.
Andrea's is faster.
Linus is considerred the leader and Alan Cox is considerred the second in command. If it's a really tough call to make then probably going with Linus is the less contraversial thing to do.
When Linus switched VM's we had gone through 10 point releases of the kernel and the VM still wasn't as stable as it should have been. If Andrea's VM took 10 releases to become stable then that would have sucked. A lot of people pointed this out to Linus in a blunt way. People thought it might take nearly that long but it only took 4.
So it worked out in the end.
Between a rock and a hard place (Score:3, Informative)
Of course, this might not fix the problem: either the patch doesn't fix enough, or the design is flawed to start with (I have not delved into either Linux VM to competently present an opinion here, just speculation on what might be wrong). But there is something to be said for "the devil you know". At least the problems with the old VM were fairly well known. Moving to a new VM could potentially introduce new ones. Not something you want to do close to release.
Now, those plagued by problems with the older VM might, in exasperation, think anything would be better. Enter Linus with Andrea's alternative: "looks good, ship it!" [my paraphrasing]. Those of us who'd tremble at the thought of new, untested code, could, well, stick to an older kernel, even if it meant giving up some new features.
But wait! It's Alan to the rescue!! Picking up all the relatively easy fixes and enhancements, and giving me a choice. Leave the contentious parts till later..
It strikes me that the minor, temporary -ac fork served both camps of users until the issues were resolved.
Some might argue for a more disciplined approach, and not make major changes so close to release. (But, if it isn't "ready", why not just postpone release? Is Linus feeling pressure to release prematurely? Or just trying to release "often enough".) But that stands in the way of progress -- I've seen managers crippled by fear of changing anything. Sometimes you gotta take a chance, even if some things break while (many) others get fixed.
While smaller, digestable kernel changes might be more palatable, they're already available in interim development releases. Sometimes a change is sufficiently profound that it touches everything (yes, that's an argument to refactor, but hindsight is 20/20, so I won't argue that point too much) and takes a while.
I am not one to say which approach is globally better -- I can only comment on what works better for me. I can say, though, that when a community is really split over a course of action, and any single choice will not satisfy a large number of people, a fork, even if temporary, is probably the least painful route in the short term, even as the long term consequences are undesirable if it goes on too long.
After all, all progress is a mini-fork from "stable" to "untested".
Re:NUMA?! (Score:2, Informative)
SuSE Inc. is a sub of SuSE AG, Germany (Score:2, Informative)
SuSE is a wholly owned subsidiary of SuSE AG, Germany. Although its US web site doesn't explicitly state that it may be deduced from
http://www.suse.com/us/company/legal/index.html
...