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".
Re:sensation seekers (Score:3, Offtopic)
Final Nissan VP agrees to stop calling it Datsun (Score:1)
Seriously though. This 'news item' is roughly akin to "Final Nissan VP agrees to stop calling it 'Datsun'".
Re:Final Nissan VP agrees to stop calling it Datsu (Score:1)
The comment you replied to has a lowercase w. Alan's diary has an uppercase w. And that's correct. Indeed, English spelling rules dictate that the first word of a sentence should be capitalized...
Re:sensation seekers (Score:4, Funny)
Re:sensation seekers (Score:1, Troll)
Sure Windows and drivers only take a few hours, but then you have to tweak it up so it's not walking with 4 toes on each foot and make sure you don't take off a leg in the process.
Then you start installing applications:
void install_program(void) {
run_installer();
reboot();
while (! last_update()) && (reboot_count 0x10) {
install_update();
reboot();
}
}
void main(void) {
while (! last_program()) && (reboot_count 1e10) {
install_program();
reboot();
}
}
That's why it takes forever.
Yes, one could argue that doing your own Linux "from scratch" would take longer (especially if you want to compile XFree), but if you have good file management, you don't have to rebuild linux every 3 months to keep it running smoothly.
Re:sensation seekers (Score:1)
Re:sensation seekers (Score:1)
good news (Score:2, Insightful)
So that's good news. J.
2.5.0, here we come! (-: (Score:2)
It's important for a lot of this new stuff to get thoroughly used so that alternatives, replacements, options and enhancements can be devised at warp speed. It's also important to have an odd kernel series active so that imaginitive new stuff has a home and doesn't stagnate.
Re:good news (Score:1)
There are other "branches" off the kernel tree for real-time kernels, etc. Getting rid of these would not be "good news".
Re:good news (Score:1)
Of course, perhaps after a while these two kernels would differ more and more from each other so that one of them gets another kernel for "special purposes" (e.g. real time kernel you mentioned above).
Another kernel tree for an area where it is clearly visible other things are needed is not bad. But two kernel where the average user don't know which one to choose are not good in my opinion.
Nice day,
j.
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?
Re:NUMA?! (Score:4, Insightful)
The VM in the mainstream kernel should be optimized for what Linux runs on 99% of the time : single CPU, with a "standard" memory bus.
With that being said, I couldn't believe that Linus made such a major change in a stable kernel. I'm glad it works, and that Alan Cox has agreed to go with it, but it wasn't an example of software engineering at its finest...
Re:NUMA?! (Score:2, Insightful)
but it wasn't an example of software engineering at its finest...
In the strictest sense... you are correct. However, engineering of any sort is a real world activity, not some dry academic subject (Wirth is full of shit on many topics, for example). Knowing when it's time to give up on a bad job, chuck it out and give something else a chance is a valuable thing (but not something to do lightly, or often).
Re:NUMA?! (Score:1)
Re:NUMA?! (Score:1)
2.0.x,2.2.x,2.4.x kernels are suposed to be safe... the 2.4.x broke this... I don't think I will trust installing a new kernel like I used to...
Re:NUMA?! (Score:1)
If you install the most recent kernel release (stable series or not) on a production box, you are a fool. No two ways about it, and it's never been any different.
I only install kernels from Redhat (they've been throughly stress tested) on important boxes. I take risks with non-essential machines.
Re:NUMA?! (Score:1)
Well, I don't disagree with you on that. Rules are meant to be broken.
But in some ways, Linus got lucky - AA's VM worked much better than RvR's, so it makes look like it was the right decision. But the real question is - if RvR's VM was so broken, how did it get in there in the first place ?
I think this is a situation where 2 wrongs made a right : bad move introducing RvR's VM when it was not ready for prime time (or at least, no tested enough to know if it was), and then switching VMs in a "stable" tree.
Re:NUMA?! (Score:1)
But in some ways, Linus got lucky - AA's VM worked much better than RvR's,
And it was accepted as a replacement because it worked better!
But the real question is - if RvR's VM was so broken, how did it get in there in the first place ?
Simple... you try something new, it doesn't work - but you don't know it isn't working until you try. The old VM "worked", in that it functioned as a VM, but certain problems came to light, and fixing them proved to be more complicated than just choosing a new, simpler, VM.
It's not as simple as saying "Linus used a broken VM."
Re:NUMA?! (Score:2, Interesting)
Something had to get there. Let me explain.
Back in 2.3.7, Linus merged a huge change that moved most file I/O from a buffer cache (caching of device blocks) to a page cache (caching based on virtual memory mappings). The VM was severely affected by this, and it never quite recovered.
So the Riel VM was not something wholly new, although it has some bits Rik put in late in the 2.3 cycle. -- But to answer your question, the "new" part of the 2.4 Riel VM was only accepted because the 2.3.7 VM was even worse.
The real question is, why did Linus stop merging Rik's VM patches back in early 2.4? At least according to Rik, Linus's VM between 2.4.5 and 2.4.9 stayed the same even though Rik was still tweaking it and submitting patches.
Re:NUMA?! (Score:2, Interesting)
I mean, how many people have access to NUMA machines, let alone own one?
All multi-processor AMD Hammer machines are / will be NUMA, so we may see a lot of mainstream users getting NUMA machines in the next few years.
That having been said, there are more linux users than just mainstream users
Re:NUMA?! (Score:4, Informative)
Re:NUMA?! (Score:2, Insightful)
Re:NUMA?! (Score:2)
One way might be to configure the slow RAM as a ramdisk and use it as swap.
Re:NUMA?! (Score:1)
Re:NUMA?! (Score:2)
Re:NUMA?! (Score:2, Informative)
More information is available: (Score:3, Offtopic)
This article is a joke... (Score:3, Offtopic)
It also says that Alan Cox will take over 2.4 once 2. 5 is opened which is wrong...
The whole war story is totally ridiculous. There has never been a talk about a fork. All there was were discussions of whether a new VM should be brought in 2.4 instead of 2.5, and some talk about the validity of benchmarks showing the improvements with the new VM.
I guess there is not much going on in the news for them to feel like writing about this...
Besides, this is nothing new since Alan Cox sayed that his last ac patch would probably be the last one with the old VM.
Re:This article is a joke... (Score:4, Informative)
Just in case somebody doesn't believe you, here's the proof [advogato.org].
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. ;)
Re:This article is a joke... (Score:1)
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
...
In related news... (Score:5, Funny)
In related news, pigs are now flying all over town, and hell just froze over.
</sarcasm>
Mod parent up! (Score:1)
why not just say linux almost contracted anthrax! (Score:1, Insightful)
from the article- The accord also ends speculation that a fragmented Linux community would be doomed in the face of Windows.
where does this ludicrious speculation come from? this sort of reporting of unsubstanciated claims is quite funny on the surface. but the more general audience reading this article will think MUCH less of the stability of the linux kernel reading crap like this. sure there is/were two different VM systems that has caused lots of posting here on ./ and probably much discussion on the kernel mailing list. how in the hell does that indicate that the linux community will be doomed in the face of windows? ARRRGGGGG!
Was there really any "dispute"? (Score:3, Insightful)
I thought the eWeek article took an unnecessarily confrontational tone.
sPh
Re:Was there really any "dispute"? (Score:2, Interesting)
Re:Was there really any "dispute"? (Score:2)
It was primarially a stability issue. To rip out a tested (but poorly performing under certain loads) VM for a brand spanking new one in the middle of a stable series was a big move. AC maintained the old VM for those who didn't want to participate in the inevitable tuning and bug-fixing that the new VM required.
It's not like it wasn't unprecedented. Andrea Arcangeli's (what a cool name!) VM rewrite eventually solved the 2.2 VM problems. But those has been dveloped as a seperate set of patches before they were incorporated into the stable 2.2 series.
Really glad to see this happen (Score:2, Flamebait)
Now, finally, we can say again : "There is one linux kernel, there are many different distributions. The kernel is the same and the different distributions differ only in programs and scripts".
Linux isn't ready for the desktop? Ohhhh crap....do I have to erase it then?
Re:Really glad to see this happen (Score:1)
Right now we have 3 kernel trees being sepperately
maintained: 2.0.38, 2.2.20, 2.4.14 are all diffrent trees.
Forking happens all of the time and it's in general a good thing if done right. People were making much too big a deal out of this.
Re:flamebait?! (Score:2)
I agree, its certainly not flamebait, just not well informed. There are many forks of the linux kernel as others have already mentioned.
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].
RHe is (Score:5, Funny)
SuSe in Oakland... (Score:2)
It turns out that the registration for suse.com does point to an office in CA. But if this moron would do some real research, he'd find out that they are infact in Germany. Of course all of us knew this.
Then again most reporters are morons..
Re:SuSe in Oakland... (Score:1)
Make your words less bitter... that way when you eat them later it won't suck so much.
Re:SuSe in Oakland... (Score:2)
the way i heard it was resolved was... (Score:4, Offtopic)
oh wait that was a michael jackson video... sorry... though still this might be as accurate as anything else...
Good news. (Score:2, Interesting)
Summary as I see it... (Score:5, Insightful)
2. Linus was stressed about it and took a brave decision to go with Andrea's VM
3. It was VERY late to be doing this, but necessary.
4. Linus' decision was correct as it turns out.
5. Alan's decision was also correct in that you shouldn't be doing this kind of dramatic about-face in a 'stable' kernel.
6. Alan's going with Andrea was also correct.
7. I've been waiting, along with many others, for this whole mess to be sorted before 2.5 was started and I upgraded kernels.
8. Passing 2.4 over to Alan means we can upgrade in confidence. This should be the test of stability for 2.6: upgrade when Linus passes it on to Alan.
Re:Summary as I see it... (Score:4, Interesting)
Even that may be a bit strong. I'd say more that it was late than poor. I'm running a recent ac kernel on one of my production servers (long story, but suffice to say that I needed a bunch of things and this turned out to be the simplest way). I was initially concerned about the Rik VM, but so far it has worked fine. Of course this is anecdotal, but I almost certainly would have had serious problems if I had installed one of the earlier 2.4 kernels, which shows progress.
Rik is right that you make things right before you make them fast; on the other hand the VM really needs to be right AND fast to be truly ready for prime time (and early releases in the 2.4.x series weren't all that "right" to begin with). The Rik VM is supposedly more advanced and featureful, but it may have simply been a bridge too far, at least given the time and resources he had to prove his ideas.
I feel sorry for Rik, but thems the breaks. He may have been right but you don't get forever to prove your ideas. At some point the clock runs out on you, even if you are really close to pulling it off.
Re:Summary as I see it... (Score:3, Insightful)
but it may have simply been a bridge too far
I think so. I always got the impression that Rik is an extremely intelligent programmer with not enough time on his hands to do the enormous job of VM writer for all of Linux.
Which was important, because it seemed, too, like he was one of a handful of people in the world that really understood how his VM system worked and, more importantly, was the ONLY one in the world that understood what needed to be done to it get it to work right.
The Days of Our Kernel (Score:5, Funny)
What better way to insure the longevity of Linux than to recruit new Kernel Hackers with tales of heated debate and intrigue (I've noticed two in the last week).
What's next, the KernelCam? Tune in to watch Linux, Alan, and the rest hacking away. View live feed of USENET postings! Only $3.99 per minute.
Strength of our style of development (Score:5, Insightful)
I like to think of Linux development as sort of a modified IETF style: rough consensus and running code, with a sprinkle of holy penguin pee when Linus thinks it's ready to ship. Linus saw a problem, had a solution presented to him, and just went for it. Alan thought it was a bit insane to switch horses in midstream. I would normally agree with Alan; better to try to get the horse you're on to do the job than try to jump to another one. Worry about getting a newer, better horse once you're safely on the other bank.
Given the time frame for 2.5/2.6, though, and given the seriousness of the VM issues, I can see why Linus decided to take the risk. Apparently so does Alan. I'm kindof anal about release numbers, so I'd probably have started a 2.5 branch to test the new VM in, and refused any other changes, then released 2.6 with the new VM. That fundamental a change should probably get a point increase in version number.
Regardless, the short version is that this is much to do about nothing. The rest of the industry just isn't used to seeing this sort of thing happen in plain view. It normally happens behind the scenes, with a carefully scripted spin put on it by marketing. Maybe if they see the process work enough times people will become comfortable with it. I doubt it.
Holy Penguin Pee (Score:2, Insightful)
This is perhaps the most beautiful description of the process I have ever heard.
I agree with you. People are used to dealing with a companies like MS, Apple, and Oracle, who are built from the ground up to never admit deficiency or the need for change even though that is a crucial aspect of any kind of upgrade cycle.
When a group of firebrands come around that can freely admit deficiency, it does cause some waves.
Re:Holy Penguin Pee (Score:1)
Actually, they do admit the need for change, but only after the new version is a fait accompli. Then it's all about why the old version needs to be upgraded. (:
One might think that vaporware hype would talk about the need for change, but for some odd reason they always seem to stress glitzy new features rather than glitzy new bugfixes. Come to think of it, for some companies this is the case even after the new version ships. (Remember BillG - getting bugs fixed is the "stupidest reason I can think of" to upgrade software.)
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".
Details please (Score:4, Interesting)
And how does it compare to VM manager in other 'nixs out there, especially FreeBSD.
Re:Details please (Score:1, Flamebait)
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.
ZDnet is not the ACM (Score:5, Insightful)
ZDnet is not the ACM; they are trying to sell magazines (or at least sponsors). A little conflict spices up the story. Should they put a more reasonable context around these things? Sure. However, if they did : "Linus and Alan agree on future" is hardly news worthy.
The more people hear about LINUX the better. (positive spin coming...)
In this context people can believe we know how to operate as open source and an effective business model. The need to evaluate, compare and when necessary compromise can be accomplished in this model for the benefit of everyone. People who appreciate that the people we want to be making business decisions for Linux.
Open Source vs Corporations (Score:5, Insightful)
Open software has an open process. That is a strength. Suggesting that just because there is disagreement in the Linux community means that it is less co-operative or cohesive than Microsoft or anyone else is utter crap. Open debate and having your own opinions are healthy signs, much better than some coerced worker toeing the company line, idependent of what is technically best.
Yeah! (Score:5, Funny)
I haven't been following this thing closely but my impression from this forum was it went something like this:
Alan: You're an idiot!
Linus: You're an idiot!
Alan: Fine! I'll take my kernel and go home!
Linus: Fine! I'll get someone else to do the kernel!
Later...
Alan: Linus, you bitch! Have you been seeing another kernel developer on the side?
Linus: Yes, but I was a fool! I love you! I've always loved you!
Alan: And I love you!
Linus: You're not an idiot!
Alan: Oh, Linus! (Kiss kiss kiss)
Linus: Oh Alan! (Kiss kiss kiss)
Linus: Oh! Alan!
Hmm. Maybe I've been reading too many romance novels lately...
Re:Yeah! (Score:2)
Re:Yeah! (Score:1, Offtopic)
What? You read romance "novels"?
Ill be reporting you to CommanderTaco for proper reeducation if this is confirmed. We will have to confiscate, and burn of course, every romance "novel" you own and re-issue you a library of SciFi proper... do not dispare commrade - THERE IS HOPE FOR YOU YET!
Media perception of Linux (Score:2, Interesting)
..."The accord also ends speculation that a fragmented Linux community would be doomed in the face of Windows."...
It seems that news about Linux is not intresting enough unless it is a struggle against Microsoft or has some doomesday issue that could cause it to "fall".
just an observation
Re:Media perception of Linux (Score:3, Funny)
one heck of a daily commute: (Score:4, Offtopic)
Re:one heck of a daily commute: (Score:1)
From 2.4.10? (Score:2, Funny)
Re:From 2.4.10? (Score:2)
What is a vm? (Score:2, Troll)
I've always been interesting in kernel coding, but some of the concepts sound pretty black-magic for me
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:virtual memory (Score:3, Funny)
>rouge programs.
Yeah. I just *hate* it when my programs end up with makeup on them . . .
:)
hawk
Re:What is a vm? (Score:2)
Settlement? (Score:2, Insightful)
But, is this really soemthign that cna be defined as "settling." As I understand it (correct me if I'm wrong) Linus put the new VM into his kernel. Its been there ever since. And its not going away. Rather Cox is giving in the Linux, as he should, since Linus is in charge. This isnt settlement, its the natural course of development. A change is proposed, Linus oks it and impelments it. Everyone else follows suit sooner or later.
I understnad the potential horror of a kernel split, but does anyoner eally ebelieve that was going to happen? Im betting Cox would rather use a far inferior VM than allow a total split, simply because of the magnitude of suhc an action.
That is good news. (Score:1)
Now if only I could get Mandrake to work on my i2o contoller, only RedHat72 seems to work for me but it is having problems booting on the 300gb raid after install. fscking disk geometry, it always gives me problems.
VM solution? (Score:1, Funny)
linux on the desktop (Score:1)
Trusted Source (meta-topic, not off-topic I hope) (Score:5, Insightful)
Have I missed something here ? I used to work in fraud investigation and there we have a dual scale of trusting information
- how trustworthy is this source ?
- how trustworthy is this source with regards to this type of information ?
(e.g. The Queen as a news source is considered trustworthy, but if The Queen told me the local 7-11 was going to be robbed at 11:30 tonight then I'd doubt the information).
Maybe that Jesse bloke really does know what he's talking about...
T
Shock as Alan Cox installs Windows (Score:2)
Shock as Alan Cox installs [new double glassed] Windows.
Phew that was close. NOT!!!
ZDNet Advertising (Score:1)
stable vm at last? (Score:1)
Differences between LINUX and FreeBSD VM design? (Score:2, Interesting)
I heard a lot of times that the *BSD desing is a lot better than the Linux, is this true ?.
Thanks for comments.
Re:Differences between LINUX and FreeBSD VM design (Score:1)
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.
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:My biggest problem with Linux was the old VM. (Score:1)
"I think Linux is going through a somewhat painful transition as it moves away from a Wild-West/Darwinist development methodology into something a bit more thoughtful. I will admit to wanting to take a clue-bat to some of the people arguing against Rik's VM work who simply do not understand the difference between optimizing a few nanoseconds out of a routine that is rarely called verses spending a few extra cpu cycles to choose the best pages to recycle in order to avoid disk I/O that would cost tens of millions of cpu cycles later on." (Read the rest of the interview here [osnews.com].)
Kakemann
Re:what crack are you smoking? (Score:1)
Re:what crack are you smoking? (Score:1)
Incorrect memory usage (Score:2, Interesting)
The AA VM "beats the pants off" Rik's VM??? (Score:3, Interesting)
Hey, I thought slashdot cited [slashdot.org] a comparison [nks.net] of the (fixed) Rik VM and the AA VM, and came to the conclusion that they performed about the same! They were both MUCH better than the 2.2 (old Rik) VM. What's Alan's evidence that the AA VM is "beating the pants off Rik'v VM?" If they really do perform about the same, I would have to side with Alan's original decision to just patch the old VM.
wait (Score:1)
Has this changed?
Newsforge (Score:1)
2 Kernels?!?! Pluh--eeeezzzee (Score:3, Insightful)
No I'm not a moron.. heh.. well maybe.. but I have two points..
1- There are not '2 kernels'.. this is crap.. there is ONE linux kernel (currently at 2.4.14.. which is development anyway.. but thats for another post
2- How is this going to ever possibly give the impression that linux is too fragmented compared to anything?! I figure (and I know this is a grevious over simplification) that there are basically two kinds of users.. those who know and those who don't. Those who know (IBM, Compaq.. those companies we want so bad) will know enough about the story to realize this is a disagreement in timing if anything and no big deal... Those who don't haven't heard about this anyway.
So other than the kernel developers needing to run both.. what's the problem?
A sensible solution to the ongoing VM dispute. (Score:2)
Re:So what? (Score:1)
Re:So what? (Score:4, Informative)
Re:Stable & reliable VM design PSE! (Score:1)
The second approach (AIX & NT) results in a smaller performance hit when real mem is exhausted - since anything that has to be swapped out already is written to disk, the VM subsystem just frees the real mem associated with the process that is being swapped out. This disk I/O costs a bit (and requires a larger swap space), but is generally faster on systems where swap usage is common.