Actually, there's some truth to his point. Say a process makes a system call and the kernel code for that call hangs in a loop. Since the scheduler won't preempt the kernel code, that process will run forever and the machine will hang. If the kernel can be preempted, the user can get to a shell and kill the stuck process. I have no idea how often this situation would happen in the real world, though. I'd think that infinite loops would be too much of a newbie bug.
I think you've misunderstood the way Linux schedules. The HZ timer tells how often the OS should call the timer interrupt (not how long a time slice is). In the timer interrupt, the OS calls the scheduler to see if any processes with higher "goodness" have become available. If none have, the scheduler continues to run the current program, until the program's quantum (time slice) runs out. This has two ramifications:
1) HZ sets an upper limit on how quickly a process can be preempted. Since the OS only checks every 10ms for a better process, a higher priority process could become available for up to 10ms before it could get to run. This is only really an issue when you're doing high-end audio work. Check either the low-latency patch pages or the preempt patch pages for some benchmarks with the 1000HZ patch for x86.
2) If all processes are of equal priority, the current process will run for up to 50ms (the 2.4 timeslice) before something preempts it. 50ms is sluggish enough that the user could notice, and could certainly kill audio latency unless the audio thread was reniced down. This is more of a problem in Linux than in other OSs because the priority of a process is not changed by the OS. In BeOS, for example, all GUI threads automatically recieve a higher priority. In fact, there is a standard set of calls for setting the priority of a thread to a value based on the type of work the thread will be performing. In Linux, the user usually has to change priorities manually, so most processes tend to be bunched up at the default priority.
One thing I really admire about Linus is that he is neither a grognard nor a pansy. He thinks that hardware detection and driver config should be automatic and he likes KDE. At the same time, he is against sissifying the kernel to meet CompUSA needs. He's also not a zealot. I read an interview with him in Boot once, and he pointed out that Microsoft really isn't evil, it just makes lousy operating systems. Also, he doesn't take a hard-line approach about the GNU/Linux thing.
Of course, one man's moderation is another's wishy-washiness...
Hmm, I don't know if the "focus" is a good thing. Particularly the thing about following other operating systems. It is rather thick-headed to believe that the Linux project can come up with all the good ideas. When one sees how much of the kernel design is based on other OSs (for example the SunOS slab allocator, the FreeBSD VM subsystem, etc) it is quite obvious that other OSs have good ideas too. By not following other operating systems, Linus does himself a disservice, because he could be learning something useful. He once made a point on a mailing list thread that Linux shouldn't do something simply because another OS does it. While this is very true, it glosses over the subtlty that, if another OS does something well a certain way, it is worth considering the design before trying to make up your own.
Hmm, I don't know if that's you're problem, but your swap/RAM distribution has problems. Rik has pretty much flat out said that your swap needs to be at least twice as large as your RAM or the VM stops working right. Either way, though, 2.4.10 does run much nicer on my end too.
Not really. The tests that have been done so far show no perceptible performance decrease. In theory, it should be slower, but I think any performance decreases from the patch are getting lost in the noise.
In practice, though, the only real disadvantage seems to be the "newness" of it. Performance, for the tests that have been conducted, seems to be the same or even better.
I think you've got some of the details wrong. First, changing the hertz timer wouldn't help anything. When people say that Linux is not preemptible, it means that when a process is running in kernel mode (as the result of a system call), the scheduler will not preempt it. It runs until it voluntarily blocks. Even if the scheduler is called more often, all that would happen is that it would allow the process to continue running more often. The result of this is that the maximum scheduling latency is dependant on the length of the system call paths. Long paths (such as disk access calls) cause spikes in latency. What the preempt patches do is they change SMP spinlocks into preemption locks. Each time a spinlock is taken, a preemption count is incremented. When it is released, the preemption count is decremented. Whenever the preemption count is zero, a context switch is allowed to happen. There is a good article here.
Actually, 1024 is about 10 times larger than 100. On BeOS, the timer interrupt is signficantly faster (either 333Hz, or 4096HZ, I forget) and it doesn't impact performance. Processors are so fast these days that the timer interrupt isn't really an issue anymore. The 1024 HZ was put in for the Alpha processor, and current x86 chips are a lot faster than the old Alphas. In fact, changing the HZ really doesn't effect anything in a normal kernel. Also, 10ms is a really long latency for audio purposes. If you want to do real time audio, you'd better be down in the few milliseconds range.
Speaking of AA's VM, does anyone actually know how it works? Rik Van Riel posted some information before he designed the VM, but I've been trying to find out about AA's VM, to no success. He says its faster and simpler and cleaner, but not how.
Ensuring compatible hardware from the onset makes life not only easier but possible. Then, 10 minute installs are the norm.
>>>>>
Not really. It took me days to install the NVIDIA drivers. First, the standard RPMS didn't have support for Mandrake 8.1, so I had to try and compile it for source. Then there were problems compiling, then there were problems with unresolved kernel symbols and whatnot. Ugh. One thing that really struck me as brain dead was putting drivers in the main source tree. Linux does it, XFree86 does it. Every other OS lets you just download a driver package (maybe including source) and install it using either a script or a GUI installer. In Linux, it seems as if developers try as hard as they can to get you to either upgrade your kernel or your version of X. Unless you stick to the kernel version that comes with your distro (which is usually a bloated POS), every driver upgrade is almost certainly accompanied by a recompile of something or the other. A driver is just a single.so, nothing more. I put the file in a directory, and it should work automagically. It should require me to recompile my kernel, the driver, or both. It should not be dependant on a particular patch-release of a kernel (binary drivers on Linux break monthly, while on BeOS they only broke during big transitions).
That's exactly what E17 is trying to do. They're even making a widget set that takes advantage of EVAS (the HW accelerated canvas). I just hope a large base of native E apps builds up.
because their desktop is better - even if the OS behind it... shall we say... lacks.
>>>>>
I get sick of hearing this all the time. Would you please care to point out exactly what is lacking? Try reading a book about the designs of both Linux and WinNT and compare the two. For where I'm sitting, WinNT has a couple of advantages. First, the VM works pretty nicely, and wasn't just rewritten a few weeks ago (although I must admit, the 2.4.10 VM has been working great so far). The sheduler seems to be better for desktop usage, as it takes into account the GUI when making sheduling decisions (which makes for a more responsive GUI). The central paradigm of an object oriented OS is light-years ahead of the antiquated UNIX "everything is a file" model. Take, for example, the ugly hack that is ioctl(). The Windows object model recognizes that everything is not a file, and makes everything an object that supports a particular interface. On the other hand, Linux has much better integration with the command line, a superior set of filesystems, and arguably better security (it is less advanced, but also less full of holes!). Thus, each OS has its advantages and disadvantages. It is a much more level playing field than it used to be. Windows != DOS anymore...
old dos code into a delphi dll.
>>>>>
It was originally old DOS code? There's your problem right there. You're probably doing something in there that Win2K doesn't like.
I think the main concern people have about resources is that other systems can do more on less. KDE and GNOME are hardly the most productive environments available. They just aren't up to the level of Windows, MacOS, or many UNIX GUIs yet. Still, they require more horsepower than any of those GUIs (aside from maybe OS-X!) Where are the cycles going? Where is the RAM going? Also, anyone will tell you that better software need not take more resources. There are tons of systems (Linux for example) that do a lot without needing inordinate resources. Besides, no matter how much power is available, there are people who use 100% of their computers. Those people don't want their computer environment sucking up resources that should be going to their power hungry apps.
I'm running a simlar spec machine (PII-300 256MB) and Win2K runs much better than either GNOME or KDE. You must have Win2K configured wrong. (That's the same comment I always hear when complaining about Linux, so I'll just dish it out myself...)
X doesn't seem to be the bottleneck since I have seen fast X apps. Qt also doesn't seem to be the bottleneck, since Qt apps run quite quickly on Windows. Try downloading the Qt "Theme" example program. It resizes beautifully, even though it has a lot of widgets on screen.
KDE-2.2 seems to have made the startup thing a little better, but what really still bothers me is widget-drawing speed. Try this little experiement. Start up Word 97 (or 2000, don't know about XP). Resize it as fast as you can. Even on a low-end machine, it will keep up with out. The widgets will move to their proper places and the worst effect will be a little (faint) flicker. Now try the same thing With KWord. When resizing to make the window smaller, there is a visible delay in the toolbars moving to their new positions. When resizing to make the window larger, there is a visible grey area in the just-resized portion before the widgets draw in. For someone who spends a lot of time futzing with windows (me) the effect is really annoying.
Seems to be a rather developer-oriented project. The cynical among us would question the priority of moving to Qt3 with regard to the fact that TrollTech employs key developers.
>>>>>>
Actually, there is nothing to be cynical about. Qt3 is a big step up from Qt2. For example, it is finally thread-safe. Qt2 was also, in theory, but threading features were unused in KDE programs because of the immaturity of Qt's thread saftey. Check out the Qt3 features list.
I don't think so; how many applications really use the GCC extensions?
>>>>>>
GNU software tends to. GLIBC uses them as does the Linux kernel. Without good GCC compatibility, a compiler is of limited usefulness as a general purpose compiler on Linux.
Slashdot Mirror
Actually, there's some truth to his point. Say a process makes a system call and the kernel code for that call hangs in a loop. Since the scheduler won't preempt the kernel code, that process will run forever and the machine will hang. If the kernel can be preempted, the user can get to a shell and kill the stuck process. I have no idea how often this situation would happen in the real world, though. I'd think that infinite loops would be too much of a newbie bug.
BeOS programming really isn't that hard. You just have to get used to the idea of locking every single thing that could possibly be shared.
SDL is to DirectX as DOS is to Linux. Not only are the two not in the same ballpark, they aren't even playing the same sport!
Damn Europeans... For the better part of the post, I wondering from what third world country you'd get developers who'd work for four dollars a month!
I think you've misunderstood the way Linux schedules. The HZ timer tells how often the OS should call the timer interrupt (not how long a time slice is). In the timer interrupt, the OS calls the scheduler to see if any processes with higher "goodness" have become available. If none have, the scheduler continues to run the current program, until the program's quantum (time slice) runs out. This has two ramifications:
1) HZ sets an upper limit on how quickly a process can be preempted. Since the OS only checks every 10ms for a better process, a higher priority process could become available for up to 10ms before it could get to run. This is only really an issue when you're doing high-end audio work. Check either the low-latency patch pages or the preempt patch pages for some benchmarks with the 1000HZ patch for x86.
2) If all processes are of equal priority, the current process will run for up to 50ms (the 2.4 timeslice) before something preempts it. 50ms is sluggish enough that the user could notice, and could certainly kill audio latency unless the audio thread was reniced down. This is more of a problem in Linux than in other OSs because the priority of a process is not changed by the OS. In BeOS, for example, all GUI threads automatically recieve a higher priority. In fact, there is a standard set of calls for setting the priority of a thread to a value based on the type of work the thread will be performing. In Linux, the user usually has to change priorities manually, so most processes tend to be bunched up at the default priority.
One thing I really admire about Linus is that he is neither a grognard nor a pansy. He thinks that hardware detection and driver config should be automatic and he likes KDE. At the same time, he is against sissifying the kernel to meet CompUSA needs. He's also not a zealot. I read an interview with him in Boot once, and he pointed out that Microsoft really isn't evil, it just makes lousy operating systems. Also, he doesn't take a hard-line approach about the GNU/Linux thing.
Of course, one man's moderation is another's wishy-washiness...
Hmm, I don't know if the "focus" is a good thing. Particularly the thing about following other operating systems. It is rather thick-headed to believe that the Linux project can come up with all the good ideas. When one sees how much of the kernel design is based on other OSs (for example the SunOS slab allocator, the FreeBSD VM subsystem, etc) it is quite obvious that other OSs have good ideas too. By not following other operating systems, Linus does himself a disservice, because he could be learning something useful. He once made a point on a mailing list thread that Linux shouldn't do something simply because another OS does it. While this is very true, it glosses over the subtlty that, if another OS does something well a certain way, it is worth considering the design before trying to make up your own.
Hmm, I don't know if that's you're problem, but your swap/RAM distribution has problems. Rik has pretty much flat out said that your swap needs to be at least twice as large as your RAM or the VM stops working right. Either way, though, 2.4.10 does run much nicer on my end too.
Except that if you're trying to do realtime manipulation of audio, you CAN'T increase the size of the buffer without introducing artifacts.
Not really. The tests that have been done so far show no perceptible performance decrease. In theory, it should be slower, but I think any performance decreases from the patch are getting lost in the noise.
In practice, though, the only real disadvantage seems to be the "newness" of it. Performance, for the tests that have been conducted, seems to be the same or even better.
I think you've got some of the details wrong. First, changing the hertz timer wouldn't help anything. When people say that Linux is not preemptible, it means that when a process is running in kernel mode (as the result of a system call), the scheduler will not preempt it. It runs until it voluntarily blocks. Even if the scheduler is called more often, all that would happen is that it would allow the process to continue running more often. The result of this is that the maximum scheduling latency is dependant on the length of the system call paths. Long paths (such as disk access calls) cause spikes in latency. What the preempt patches do is they change SMP spinlocks into preemption locks. Each time a spinlock is taken, a preemption count is incremented. When it is released, the preemption count is decremented. Whenever the preemption count is zero, a context switch is allowed to happen. There is a good article here.
Actually, 1024 is about 10 times larger than 100. On BeOS, the timer interrupt is signficantly faster (either 333Hz, or 4096HZ, I forget) and it doesn't impact performance. Processors are so fast these days that the timer interrupt isn't really an issue anymore. The 1024 HZ was put in for the Alpha processor, and current x86 chips are a lot faster than the old Alphas. In fact, changing the HZ really doesn't effect anything in a normal kernel. Also, 10ms is a really long latency for audio purposes. If you want to do real time audio, you'd better be down in the few milliseconds range.
Speaking of AA's VM, does anyone actually know how it works? Rik Van Riel posted some information before he designed the VM, but I've been trying to find out about AA's VM, to no success. He says its faster and simpler and cleaner, but not how.
PS> Yea I know, its called "grep"
Ensuring compatible hardware from the onset makes life not only easier but possible. Then, 10 minute installs are the norm. .so, nothing more. I put the file in a directory, and it should work automagically. It should require me to recompile my kernel, the driver, or both. It should not be dependant on a particular patch-release of a kernel (binary drivers on Linux break monthly, while on BeOS they only broke during big transitions).
>>>>>
Not really. It took me days to install the NVIDIA drivers. First, the standard RPMS didn't have support for Mandrake 8.1, so I had to try and compile it for source. Then there were problems compiling, then there were problems with unresolved kernel symbols and whatnot. Ugh. One thing that really struck me as brain dead was putting drivers in the main source tree. Linux does it, XFree86 does it. Every other OS lets you just download a driver package (maybe including source) and install it using either a script or a GUI installer. In Linux, it seems as if developers try as hard as they can to get you to either upgrade your kernel or your version of X. Unless you stick to the kernel version that comes with your distro (which is usually a bloated POS), every driver upgrade is almost certainly accompanied by a recompile of something or the other. A driver is just a single
That's exactly what E17 is trying to do. They're even making a widget set that takes advantage of EVAS (the HW accelerated canvas). I just hope a large base of native E apps builds up.
Interesting comment. That brings up the question... Should the mainstream cater to those who are asthetically blind?
because their desktop is better - even if the OS behind it... shall we say... lacks.
>>>>>
I get sick of hearing this all the time. Would you please care to point out exactly what is lacking? Try reading a book about the designs of both Linux and WinNT and compare the two. For where I'm sitting, WinNT has a couple of advantages. First, the VM works pretty nicely, and wasn't just rewritten a few weeks ago (although I must admit, the 2.4.10 VM has been working great so far). The sheduler seems to be better for desktop usage, as it takes into account the GUI when making sheduling decisions (which makes for a more responsive GUI). The central paradigm of an object oriented OS is light-years ahead of the antiquated UNIX "everything is a file" model. Take, for example, the ugly hack that is ioctl(). The Windows object model recognizes that everything is not a file, and makes everything an object that supports a particular interface. On the other hand, Linux has much better integration with the command line, a superior set of filesystems, and arguably better security (it is less advanced, but also less full of holes!). Thus, each OS has its advantages and disadvantages. It is a much more level playing field than it used to be. Windows != DOS anymore...
old dos code into a delphi dll.
>>>>>
It was originally old DOS code? There's your problem right there. You're probably doing something in there that Win2K doesn't like.
I think the main concern people have about resources is that other systems can do more on less. KDE and GNOME are hardly the most productive environments available. They just aren't up to the level of Windows, MacOS, or many UNIX GUIs yet. Still, they require more horsepower than any of those GUIs (aside from maybe OS-X!) Where are the cycles going? Where is the RAM going? Also, anyone will tell you that better software need not take more resources. There are tons of systems (Linux for example) that do a lot without needing inordinate resources. Besides, no matter how much power is available, there are people who use 100% of their computers. Those people don't want their computer environment sucking up resources that should be going to their power hungry apps.
I'm running a simlar spec machine (PII-300 256MB) and Win2K runs much better than either GNOME or KDE. You must have Win2K configured wrong. (That's the same comment I always hear when complaining about Linux, so I'll just dish it out myself...)
X doesn't seem to be the bottleneck since I have seen fast X apps. Qt also doesn't seem to be the bottleneck, since Qt apps run quite quickly on Windows. Try downloading the Qt "Theme" example program. It resizes beautifully, even though it has a lot of widgets on screen.
KDE-2.2 seems to have made the startup thing a little better, but what really still bothers me is widget-drawing speed. Try this little experiement. Start up Word 97 (or 2000, don't know about XP). Resize it as fast as you can. Even on a low-end machine, it will keep up with out. The widgets will move to their proper places and the worst effect will be a little (faint) flicker. Now try the same thing With KWord. When resizing to make the window smaller, there is a visible delay in the toolbars moving to their new positions. When resizing to make the window larger, there is a visible grey area in the just-resized portion before the widgets draw in. For someone who spends a lot of time futzing with windows (me) the effect is really annoying.
Seems to be a rather developer-oriented project. The cynical among us would question the priority of moving to Qt3 with regard to the fact that TrollTech employs key developers.
>>>>>>
Actually, there is nothing to be cynical about. Qt3 is a big step up from Qt2. For example, it is finally thread-safe. Qt2 was also, in theory, but threading features were unused in KDE programs because of the immaturity of Qt's thread saftey. Check out the Qt3 features list.
I don't think so; how many applications really use the GCC extensions?
>>>>>>
GNU software tends to. GLIBC uses them as does the Linux kernel. Without good GCC compatibility, a compiler is of limited usefulness as a general purpose compiler on Linux.