So what specific part of SuSE's 2.6 test plan do you think is insufficient?
Oh wait, sorry. You're spouting off with no real knowledge of what they're doing at all. My mistake.
Change necessitates risk. Risk necessitates risk management. The shit needs testing whether you backport or upgrade. The question is whether you want to forward-port forked code for ever, or merge back with mainstream.
The fact that SuSE got merged up before RH doesn't really mean that much. They both do exactly the same thing, just on a slightly different timescale. Check out the 1000 or so SuSE patches they have against their own (currently shipping) 2.4 kernel.
OK, I've been doing this for years, and am a full time kernel hacker. So this is not "I'm a newbie", these are IMHO just *broken*. Some of these are Debian, since that's what I use. The other distros are IMHO more broken in some other way (depending on the distro).
1. Debian is a pain in the ass to install. People, get it together - put a standard, official netboot ISO up for download for each version of Debian that actually works, and supports more than 2 network cards. And try to actually autodetect the net card so I don't have to grope around flicking to another window and cat'ing/proc/pci to find out what I have.
2. Debian has far too many packages, and 10 solutions to everything. Have recommended packages for things like "audio mixer". Oooh, politics... scary. Deal with it.
3. X is still a pain in the ass to set up. I've been doing this since 1993, and it STILL takes me over an hour, and the loss of a bunch of hair every time.
4. All the window managers are either fat & bloated or flaky as hell. And normally both.
5. X permissions (xauth, etc) are just CRAP.
6. "scp file foo@bar" just does a normal cp, without objecting to the fact that I ommited a ":" at the end. Why the fuck would I use scp to do a local file copy?
7. File compression is not transparent. I hate doing "bzcat patch-file.bz2 | patch -p1". Would be much easier to do "patch -p1 patch-file.bz2". And don't whine about wrappers. The right place to fix this is probably the fs layer.
8. We need less "oh, but you can fix X by doing Y then Z, and standing on your head", and more "it just works. Out the box. without fiddling with shit".
9. Fonts. Enough said.
10. GNU's fucked up arrogant attitude to man pages. No, I don't want a fucking info page, at least for the basics. You shouldn't have made it such a bloated piece of featuritus'ed crap in the first place.
But the cpu beign 90% utilized includes time for memory stalls...
I've done a lot of testing on kernel compiles... on machines with enough memory to cache the whole thing. Do a second compile afterwards with warm caches - it takes almost exactly the same time - it's NOT IO bound. (normally done with "make -j N" vmlinux) where N is 2x the number of CPUs.
I actually *do* try to do that in the -mjb tree already... I collect bug fixes, performance improvements, and diagnostics tools (so if it does break, you can find what went wrong).
Staying one kernel release back will help you too... ie we're on 2.5.66 now, so run 2.5.65-mjb2 (the latest 65 version). And don't turn on preempt (it's broken in my tree by something I did).
The interactivity tweaks are against the O(1) scheduler, so won't do you much good in 2.4.. unless you run 2.4-aa or something.
If you're going to upgrade from 2.4 to 2.5, make sure you compile import support in (not off, or as a module), and turn VT console support on explicitly. Those are the usual tarpits for new 2.5 people.
That's mainly because multiple large corporations constantly run benchmarks on big-assed machines and kick the living snot out of the 2.5 kernel, report bugs and fix them. Every frigging day, every kernel release. And the fact that people like Andrew have far too much talent for their own good;-)
Crap. You have 4 gigs of virtual address space. You have up to 64GB of physical (eg RAM). Go search for "PAE". OK, it's a pain the ass to write OSes for, but it works.
For one, this was submitted before the feature freeze, which was the requirement that came down from Linus, not "merged by the feature freeze". It just got cleaned up since then.
Secondly, the reason Linus accepted this was not that it came from IBM, it's that it was split up into small readable pieces, well documented, and obviously had no effect WHATSOEVER on standard machines.
It's pathetic that you think Linus has so little personal integrity that he'd take bribes to put patches into the kernel. And who said this code was untested?
SGI's stuff is (I believe) supported by their own 2.4-based tree, and is pretty much unmergable back into mainline.
This is about stuff that's designed to be non-invasive enough to go into the mainline kernel, less bells and whistles, but a longer term goal, designed to work on every architecture. We'll slowly add features to it as they come up, if they're well tested across multiple arches and make sense.
No. You're still limited by the 36 bit PAE addressing scheme on intial ia-32 processors, as all memory is universally adressable, albeit at different speeds.
We do end up with lots of PCI buses, etc. With careful programming, this gives you a shitload of IO bandwidth.
IBM is not even hosting it, they're just donating some time to help administer it. Sigh... people's level of paranoia is just amazing. I'm not sure how you think this is going to mind-control the community somehow.
Memory bandwidth has nothing to do with Operating System scalability. Only a marketing person could have dreamed up that press release.
If you actually *do* anything realistic (like run a database), scalability will be nothing like linear. On the other hand, we are working hard towards that goal....
Slashdot Mirror
So what specific part of SuSE's 2.6 test plan do you think is insufficient?
Oh wait, sorry. You're spouting off with no real knowledge of what they're doing at all. My mistake.
Change necessitates risk. Risk necessitates risk management. The shit needs testing whether you backport or upgrade. The question is whether you want to forward-port forked code for ever, or merge back with mainstream.
The fact that SuSE got merged up before RH doesn't really mean that much. They both do exactly the same thing, just on a slightly different timescale. Check out the 1000 or so SuSE patches they have against their own (currently shipping) 2.4 kernel.
No, that's not what we say.
We do say we have no way of working out whether it was the cause or not, so fuck off and work it out yourself by removing that crap from the kernel.
OK, I've been doing this for years, and am a full time kernel hacker. So this is not "I'm a newbie", these are IMHO just *broken*. Some of these are Debian, since that's what I use. The other distros are IMHO more broken in some other way (depending on the distro).
/proc/pci to find out what I have.
... scary. Deal with it.
1. Debian is a pain in the ass to install. People, get it together - put a standard, official netboot ISO up for download for each version of Debian that actually works, and supports more than 2 network cards. And try to actually autodetect the net card so I don't have to grope around flicking to another window and cat'ing
2. Debian has far too many packages, and 10 solutions to everything. Have recommended packages for things like "audio mixer". Oooh, politics
3. X is still a pain in the ass to set up. I've been doing this since 1993, and it STILL takes me over an hour, and the loss of a bunch of hair every time.
4. All the window managers are either fat & bloated or flaky as hell. And normally both.
5. X permissions (xauth, etc) are just CRAP.
6. "scp file foo@bar" just does a normal cp,
without objecting to the fact that I ommited
a ":" at the end. Why the fuck would I use
scp to do a local file copy?
7. File compression is not transparent. I hate
doing "bzcat patch-file.bz2 | patch -p1". Would be much easier to do "patch -p1 patch-file.bz2". And don't whine about wrappers. The right place to fix this is probably the fs layer.
8. We need less "oh, but you can fix X by doing Y then Z, and standing on your head", and more "it just works. Out the box. without fiddling with shit".
9. Fonts. Enough said.
10. GNU's fucked up arrogant attitude to man pages. No, I don't want a fucking info page, at least for the basics. You shouldn't have made it such a bloated piece of featuritus'ed crap in the first place.
But the cpu beign 90% utilized includes time for memory stalls ...
... on machines with enough memory to cache the whole thing. Do a second compile afterwards with warm caches - it takes almost exactly the same time - it's NOT IO bound. (normally done with "make -j N" vmlinux) where N is 2x the number of CPUs.
I've done a lot of testing on kernel compiles
I actually *do* try to do that in the -mjb tree already ... I collect bug fixes, performance improvements, and diagnostics tools (so if it does break, you can find what went wrong).
... ie we're on 2.5.66 now, so run 2.5.65-mjb2 (the latest 65 version). And don't turn on preempt (it's broken in my tree by something I did).
.. unless you run 2.4-aa or something.
Staying one kernel release back will help you too
The interactivity tweaks are against the O(1) scheduler, so won't do you much good in 2.4
If you're going to upgrade from 2.4 to 2.5, make sure you compile import support in (not off, or as a module), and turn VT console support on explicitly. Those are the usual tarpits for new 2.5 people.
That's mainly because multiple large corporations constantly run benchmarks on big-assed machines and kick the living snot out of the 2.5 kernel, report bugs and fix them. Every frigging day, every kernel release. And the fact that people like Andrew have far too much talent for their own good ;-)
2.6 *will* rule the world.
Bollocks. 2.5 is more stable than 2.4 now, apart from a shedload of broken drivers. Try actually stressing the 2.4 VM.
What we need is a honey pot full of fake SSNs ... when people try to use them (obviously stolen), the Feds go round and arrest the bastards.
Crap. You have 4 gigs of virtual address space. You have up to 64GB of physical (eg RAM). Go search for "PAE". OK, it's a pain the ass to write OSes for, but it works.
What a crock of shit. You might find gcc 3.2 is faster for some little microbenchmark, but look at this thread for some real world numbers:
1 04 431408416381&w=2
... conclusion: it produces slightly slower, rather larger code, and takes much more time to do it.
http://marc.theaimsgroup.com/?l=linux-kernel&m=
Follow it all the way down
For one, this was submitted before the feature freeze, which was the requirement that came down from Linus, not "merged by the feature freeze".
It just got cleaned up since then.
Secondly, the reason Linus accepted this was not that it came from IBM, it's that it was split up into small readable pieces, well documented, and obviously had no effect WHATSOEVER on standard machines.
It's pathetic that you think Linus has so little personal integrity that he'd take bribes to put patches into the kernel. And who said this code was untested?
Martin J. Bligh.
SGI's stuff is (I believe) supported by their own 2.4-based tree, and is pretty much unmergable back into mainline.
This is about stuff that's designed to be non-invasive enough to go into the mainline kernel, less bells and whistles, but a longer term goal, designed to work on every architecture. We'll slowly add features to it as they come up, if they're well tested across multiple arches and make sense.
Martin J. Bligh.
No. You're still limited by the 36 bit PAE addressing scheme on intial ia-32 processors, as all memory is universally adressable, albeit at different speeds.
We do end up with lots of PCI buses, etc. With careful programming, this gives you a shitload of IO bandwidth.
Martin J. Bligh.
> The performance and scalability is like nothing
....
> that has ever run Linux and is *far* ahead of the > competition.
Pft. I bet IBM Regatta running PPC64 chips still
kicks this thing's ass. Benchmarks
So people should switch to MS because Linux has bugs in it's 2.5 *DEVELOPMENT* kernel that we're
actively working on fixing. Yeah. Right.
IBM is not even hosting it, they're just donating some time to help administer it. Sigh ... people's level of paranoia is just amazing. I'm not sure how you think this is going to mind-control the community somehow.
Crap. What do you think PAE mode does? You can put 64GB of RAM on ia32 based hardware.
64-bit gives you a 64 bit VIRTUAL address space.
Doubling the number of processors will NOT make it go twice as fast, unless you're just running crappy unrealistic simple benchmarks.
Define scale - it all depends on the workload. Memory bandwidth is easy for the software, though impressive for the hardware to push that much.
Of course, an ia64 runs Linux like a wet turd, which is probably why they didn't publish any real benchmark figures.
Memory bandwidth has nothing to do with Operating System scalability. Only a marketing person could have dreamed up that press release.
....
If you actually *do* anything realistic (like run a database), scalability will be nothing like linear. On the other hand, we are working hard towards that goal
So when are you going to do a Thai food episode? You know you want to ....
No it isn't. It's a totally different generation of hardware.
1. 2.4.18, and I also told you what patches I was using (though some of them won't be published until next week).
2. OK, I just posted the config file. http://lse.sourceforge.net/numa/config.mem
3. I did five kernel compiles in a row (though I omitted to mention that).
Oh, and BTW, yes this hardware is about 2 years old.
Don't forget to add about $10,000 per quad for the custom interconnect, which is what really makes this machine work