2 cores vs. 4 cores in Linux

[kraftman]

Apparently "The Bazaar" does not do regression testing, either.

How do bugs like this make it into "RC" kernels? Does not "RC" mean "we have tested this and we think it is good"?

This is one reason why Linux has crummy market share. There are so many regressions. Normal non-hacker type people do not want to deal with regressions. They want to turn their computers on and get to work.

I wonder what can be done to deal with the regressions. Linux has no central testing lab and no formal process.

With a formal process, you are not even half done when you fix the bug. Next you have to write the regression test for the bug and then test the regression test. This usually takes more effort and more resources than fixing the bug. And then you have to run all the regression tests all the time. This requires an automated framework to run the regression tests and report the results. This is all enormous work but it needs to be done if you want to ship a quality product every time.

When you look at the bugzilla.kernel.org, there is not even a bug status for "needs testing". When something is "fixed" it gets marked as RESOLVED and that is that.

RedHat etc. have to do this testing and their kernels have hundreds of patches to the stock kernels to fix the problems that are not caught by the "Bazaar" process. When you look at these patches you see that most of them are fixes for regressions, things that used to work and then stopped working for some reason, and the regression was not caught. Or else they are driver patches for new drivers that never worked right in the first place because they did not get tested well. Some of the distribution patches stick around for years because they do not get accepted upstream for one reason or another. These patches need to be maintained as the code changes and that requires even more effort.

I don't know how it can be fixed. Nobody "owns" linux, so nobody wants to take the responsibility to do all the regression testing that should be done. The distributions "own" their kernels, but if they all do their own regression testing then there is enormous duplicated effort.

I worry that Linux is going to turn into even more of a chaotic mess as it gets bigger and gets more features. It is not the slim and trim kernel that it was back in the 90's.

Thanks for confirming what I suggested before. I wonder why Linux already killed Solaris? There's Linux's performance team etc. However, it doesn't matter.

I worry that Linux is going to turn into even more of a chaotic mess as it gets bigger and gets more features. It is not the slim and trim kernel that it was back in the 90's.

This is what killed Solaris and other commercial Unixes. They're dying dinosaurs. It's just opposite when comes to Linux, but if you don't have anything smart to say why don't you just shut up? I know - you're a troll and you're on my ignore list now :> If you really want such flame post a new thread and pm me, because you're 'trashing' here.

@Krazy

Can you describe your problem little more? Do you notice long pauses when copying big file? Is rc5 much better or just little? I have to compile some more things to make X working and to try it

[frantaylor]

Hey kraftman, do you know what "criticism" is?

It does not mean "I hate this"

It means "I like this and I want it to be better"

If I hated Linux I would not bother to post.

[frantaylor]

Does anyone work with channel bonding and multiple cores? I used it
many years ago with ISDN and it did not work with SMP then. I hear
that they fixed it but I get kernel panics when I try to use it.

Gigabit Ethernet is not fast enough for my application. Used Infiniband cards are cheap on ebay but the cabling is too expensive. I want to try four channel-bonded gigabit ethernets, if I can get 3 Gb/sec then that would be great.

I am waiting for gear to show up in the mail so I can do some more experiments, but I wonder if anyone out there has tried the bonding driver with 2 or 4 or 8 cores and how well it works for them.

[RealNC]

Linux is mostly developed by individuals that work for companies doing "server" and "workstation" work with Linux. A bug that affects GUI/Multimedia is quite irrelevant to those people, especially if fixing it would mean performance regressions in servers/workstations. If we consider Linux market share on the server side being over 13% while home desktops being under 2 or 3%, you can guess the priorities of the majority of kernel devs. If Linux would target the Desktop equally, it would never had become so popular on servers.

[kraftman]

Linux is mostly developed by individuals that work for companies doing "server" and "workstation" work with Linux. A bug that affects GUI/Multimedia is quite irrelevant to those people, especially if fixing it would mean performance regressions in servers/workstations. If we consider Linux market share on the server side being over 13% while home desktops being under 2 or 3%, you can guess the priorities of the majority of kernel devs. If Linux would target the Desktop equally, it would never had become so popular on servers.

It's not exactly like this. Linux is made mainly by IBM, Intel, HP and many other companies (they test it on their machines like 'big irons', their servers, desktops etc). This bug is not multimedia one. It's not like this: focus 3/4 one servers and 1/4 on desktops. Solaris was focused on servers. However, it really goes to flame, so let's focus on topic and mentioned bug?

Hey kraftman, do you know what "criticism" is?

It does not mean "I hate this"

It means "I like this and I want it to be better"

If I hated Linux I would not bother to post.

Ok, I didn't saw this, but this thread isn't about criticism. I've got very different feeling from yours, so if you want to continue let's post this in another thread?

I like Solaris and FreeBSD (however, I want them dead, but it's another story and if I have such bug under Linux like mentioned before I can use them instead), but I don't criticize them here :P

[frantaylor]

Linux is mostly developed by individuals that work for companies doing "server" and "workstation" work with Linux. A bug that affects GUI/Multimedia is quite irrelevant to those people, especially if fixing it would mean performance regressions in servers/workstations. If we consider Linux market share on the server side being over 13% while home desktops being under 2 or 3%, you can guess the priorities of the majority of kernel devs. If Linux would target the Desktop equally, it would never had become so popular on servers.

One of these days real soon now, Microsoft is going to have a major meltdown. Someone will uncover a truly terrible security bug and half of the users on the Internet are gonna get 0wned. For all we know it is already happening with the ActiveX fiasco. It will be a major opportunity for Linux to step up to the plate, but they won't be ready for it. Apple will have a cut-price sale, that big teeter-totter in the sky will flip over to OSX, and Linux will have missed the opportunity. Apple will take over from Microsoft, they will get big and complacent and suck just as bad as Microsoft. Nothing will really change and Linux will still be at 2%. I don't like it but I can't see any other scenario.

[frantaylor]

I see "2 cores vs. 4 cores" at the top of this page so I assume that is what the thread is.

So I wanna talk about NICs in this context. I want to set up a really bad-ass file server. I have lots of huge files (30 Gb each!) to backup and I hate to wait. I just want to blast them over to my file server ASAP. When I mess them up on my workstation I want to copy them back from the file server ASAP. There will be other users but they have very minor requirements compared to mine. However it would be nice if they get responsive behavior even when I am making my huge copies.

I want to know how many cores to put in my file server and what NICs to use that will work best with that many cores. I've already done my homework on the disk controller and I don't want to talk about that.

I don't even care what OS it runs, just that it has first-class NFS4 service. I would prefer Linux because I know it best. If there is something that works perfect out of the can, that would be best, but I am willing to fiddle around if I have to. I can see from the discussion here that Linux is not a slam-dunk.

Hey kraftman, is this something that you share an interest in? Surely you can tell me if 2 cores is sufficient or if I need 4? And do you know what would be the most stable kernel? I want speed, but data corruption is intolerable.

[krazy]

@Krazy

Can you describe your problem little more? Do you notice long pauses when copying big file? Is rc5 much better or just little? I have to compile some more things to make X working and to try it

The problem with that bug report is that it was so vague that my problem could be completely different to your problem

Anyway, I was having issues with copying to USB flash drive from my SATA HDD. Eg copying 3 ~700-800 MB files would work fine for the first ~1 GB or so and then slow right down to 0 kbps, speeding up for a couple of seconds, then back to 0 for a few more seconds (for the rest of the transfer). This final stage could last for up to 40 mins, and even after it had "finished" copying, the IO wait process would eat up 100% of one CPU core for another 10 mins before I could 'safely remove' the flash drive.

[energyman]

well, I have a X2 6000+ and I will get a X4 955 on Monday. I compile a lot and that does benefit tremendously.

About the io-problem. There are ways and workarounds. Some people have the problem, some have it and can solve it, some can't. But since almost nobody with the problem ever complains on lkml it will probably never fixed. So if you see this io-hangs, go to lkml. Thank you.

[kraftman]

The problem with that bug report is that it was so vague that my problem could be completely different to your problem

Anyway, I was having issues with copying to USB flash drive from my SATA HDD. Eg copying 3 ~700-800 MB files would work fine for the first ~1 GB or so and then slow right down to 0 kbps, speeding up for a couple of seconds, then back to 0 for a few more seconds (for the rest of the transfer). This final stage could last for up to 40 mins, and even after it had "finished" copying, the IO wait process would eat up 100% of one CPU core for another 10 mins before I could 'safely remove' the flash drive.

Yes, my problem is different. However, if I remember I saw issue like yours. Can you check: hdparm -Tt /dev/hda [sda]

and post the results?

Maybe you can try this:

http://linux-ata.org/faq.html

"Intel combined mode".

@Frantaylor

I've already done my homework on the disk controller and I don't want to talk about that.

It seems you didn't and that's why you don't want to talkt about this. However, another thread can verify this :>.