Hugo Vanwoerkom wrote:
Hugo Vanwoerkom wrote:Hi, I don't really think this is OT, albeit not directly Debian related.Con Kolivas, the kernel hacker who authored a better scheduler, recently decided to quit.Loss for Linux (and Linus) Here's his reasoning.http://apcmag.com/6735/interview_con_kolivas
I'd like to preface this by saying that I am not a Linux hater. Nor am I a MicroSoft hater. I won't go so far as to say that there is any OS for my machine I actually *like*. Each OS I can run has advantages and disadvantages. So far, I find that Linux provides me what I want moreso than the others FOR THIS MACHINE. On other machines, with other uses, I use other OSs. I have no particular axe to grind with any of them. I've written a couple of kernels, and supported perhaps four more, for embedded real time systems. I found this particular quote about the scheduling from that article very revealing: [QUOTE MODE ON]The option is to throttle the guessing, or not guess at all. The former option means you have a CPU scheduler which is difficult to model, and the behaviour is right 95% of the time and ebbs and flows in its metering out of CPU and latency. The latter option means there is no guessing and the behaviour is correct 100% of the time... it only gives what you tell it to give. It seemed so absurdly clear to me, given that interactivity mostly was better anyway with the fair approach, yet the maintainers demanded I address this as a problem with the new design. I refused. I insisted that we had to compromise a small amount to gain a heck of a great deal more. A scheduler that was deterministic and predictable and still interactive is a much better option long term than the hack after hack approach we were maintaining.
[QUOTE MODE OFF] Any RTOS developer and maintainer will tell you that the only way to be able to tweak and predict the results is to have reliable, dependable, predictable scheduling algorithms. In fact, in any system where one is trying to tweak CPU performance, not just RTOS where one must meet absolute deadlines, having a non-real-time scheduler just makes the job impossible. His other commentary aside, some of which I agree with and some I do not, this one point makes a lot of sense to me, as a non- Linux kernel specialist (in both the sense of not being a specialist in Linux kernel, and being a specialist in some non-Linux kernels). I have myself run some CPU benchmarks on various OS my machine can run, and Linux (Fedora Core 2 [*]) is by far the slowest of the ones I have tried. That's ok, as it also has more services than most of the ones I tried. (I found that XP is faster on my machine than Linux, and I believe it supplies as many services I want as Linux does.) I have tried running some long-term computations in the background using my machine, and found that nice was unable to deal with it. Exactly the points he brings up... momentary freezes of the display (5-10 seconds) lots of ghosting of moving mouse pointers and windows momentary freezing of the keyboard (up to 30 seconds) difficulty switching "workspaces" using GNOME (minutes delay) very extended load times for apps (minutes to load acrobat, e.g.) This is on a 2.7 GHz machine with 250Meg of memory. Some of this is explainable as memory thrashing, as evidenced by disc activity, and memory pressure reported by top and similar tools. But, why is my disc running when I try to move my mouse? Also, even when my machine is otherwise unloaded, I find that prelink gets charged up, or updatedb, and I lose control of my machine for up to 30 minutes at a time. I hear that prelink, at least, has been modified somewhat to alleviate this. But on my machine it sometimes takes 2-3 seconds for a character to be echoed in a terminal window. On a 2.7GHz machine? WTH can it be doing all that time? With a proper scheduler, prelink would not be able to eat my CPU like that. (One could also argue that prelink shouldn't even exist, but that's a different discussion.) Another well-known hog is yum, which I have myself seen eat my machine. Again, with a proper scheduler this would not happen. (Yes, I know that apt-get is the Debian way, but we're discussing the kernel and scheduling. If I installed and ran yum on my girlfriend's Debian machine, it would do the same thing, I trow. An application should not be able to eat my machine and wrest control away from the display manager and keyboard interface.) There seem to me to be two areas where Linux could use some serious improvment: (1) better CPU resource management (2) better memory resource management (machine thrashes when it shouldn't) When, on occasion, I have posted to various Linux mail lists (I subscribe to three) about these performance issues, there have been five cookie-cutter responses (one might almost say knee-jerk)(1) you are stupid, Windows eats lots of CPU as everyone knows, you are wrong, Linux is faster, your benchmark is wrong, the way Linux manages
memory and disc is just about optimum (2) but Linux does so much MORE (than XP? no, it doesn't) (3) get more machine (CPU, RAM, especially RAM) (4) go back to Windows, you deserve it, you are a Linux hater, we don't need people like you on the Debian mail list anyway, you are against everything Linux stands for (what does an OS stand for? it's a way to manage hardware and load and execute apps) (5) what a whiner: get in there and fix it or shut up Nobody has ever responded "Hmm, that's interesting. I wonder whether it should be investigated and fixed." Now, I see one guy who actually tried (though it doesn't sound like he is very knowledgeable about scheduling algorithms) but failed to make any real difference. And now he's quitting, because he realizes that it's hard to make any headway against the crowd. Linux is as much an article of faith to those who use it and defend it, as is Windows to those who use it and defend it. Criticisms seem to roll of the backs of those who are true believers, even if they are offered in a spirit of friendship, and hope for a change for the better. I think he finally realized that. Just my $0.02. YMMV [*] $ uname -aLinux Presario-1 2.6.10-1.771_FC2 #1 Mon Mar 28 00:50:14 EST 2005 i686 i686 i386 GNU/Linux
It took my machine 3 seconds to do a "copy" after selecting
that text on my screen, because the disc ran that long after
I clicked on the "Edit" button on the window frame. It had to hit
disc to load the image and/or software needed to copy the selected
text. I am running Thunderbird, one instance of Netscape, one instance
of acroread 7.0, and four xterm windows.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
