"Con Kolivas is a prominent developer on the Linux kernel and strong proponent of Linux on the desktop. But recently, he left it all behind. Why? In this interview with APCMag.com, Con gives insightful answers exploring the nature of the hardware and software market, the problems the Linux kernel must overcome for the desktop, and why despite all this he's now left it all behind."
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-07-12
Sure it is. With the "2.6.20-16-lowlatency #2 SMP PREEMPT" in ubuntu feisty, an Opteron 180, 3 GiB RAM (almost all of which was free) and swaps on 3 different disks I yesterday tried running 7 "nice -n 19 memtest 500M" and immediately when the mouse pointer froze I typed "killall memtest<Enter>", but still the computer was as good as dead for about an hour. Nothing should make the mouse pointer freeze for an hour (or even a few seconds), even if the computer had the world on its shoulders. That a few nice-19 processes accessing a few hundred more megs ram than is available puts it into a deep coma is inexcusable, and it's most certainly Linux' fault.
It would be interesting to know the results when you use BSD, so we know if it really is Linux' fault or X.
Member since:2005-07-06
> It would be interesting to know the results when you
> use BSD, so we know if it really is Linux' fault or X.
Well, considering Alt-SysRq-r didn't help me Ctrl-Alt-F1 to a console I'd say it's certainly linux' fault. It's not like "oh, the kernel is alive and well, it's just everything else that refuse to do anything". If the kernel wouldn't be in a coma I'm sure the rest of the system wouldn't either. At least in this case.
Member since:2007-01-24
Member since:2005-07-24
"""
With the "2.6.20-16-lowlatency #2 SMP PREEMPT" in ubuntu feisty, an Opteron 180, 3 GiB RAM (almost all of which was free) and swaps on 3 different disks I yesterday tried running 7 "nice -n 19 memtest 500M" and immediately when the mouse pointer froze I typed "killall memtest<Enter>", but still the computer was as good as dead for about an hour.
"""
I hope you find out what is wrong with your hardware.
I just tried the same thing on my sempron 2800+ laptop with 768MB of ram, also running feisty, while listening to a 192kb/sec internet radio station coming in over the wireless nic. I didn't bother to nice it, though.
Silky smooth mouse. Audio stream didn't skip a beat.
Member since:2005-07-06
> > 7 "nice -n 19 memtest 500M"
>
> I hope you find out what is wrong with your hardware.
There's nothing wrong with it. Linux behaves the same way on all hardware I've ever tested it on.
> I just tried the same thing on my sempron 2800+ laptop
> with 768MB of ram, also running feisty, while listening
> to a 192kb/sec internet radio station coming in over the
> wireless nic.
You ran seven "memtest 500M" on 768M of ram while still being able to listen to music? I don't believe you for even a fraction of a second. How much swap do you have? Sure that those memtests weren't killed?
Member since:2005-09-21
Nothing should make the mouse pointer freeze for an hour (or even a few seconds), even if the computer had the world on its shoulders.
As sbergman27 has already mentioned, either your hardware is defective, or your kernel/drivers is seriously malfunctioning. I did the same test (2GB RAM), with and without the nice, and the computer didn't skip a beat. Music kept on playing, mouse kept moving. Overall I find the responsiveness of Linux to be far better than Windows on the same hardware. While a lot of hard drive and CPU activity tends to make the Windows GUI grind to a halt, I barely notice on Linux when I've got a compile going in the background.
Member since:2005-07-06
> either your hardware is defective, or your kernel/drivers
> is seriously malfunctioning. I did the same test (2GB
> RAM), with and without the nice, and the computer didn't
> skip a beat. Music kept on playing, mouse kept moving.
Hmm.. I just tried running some memtests on my laptop on the console and with only a gdm running X. The system didn't become very unresponsive, but some memtest immediately got killed if I tried getting even close to the RAM limit. The laptop has 2 GiB of RAM and a swap partition and trying to run 4 "memtest 500M" almost immediately kille done of them.
Then I logged on using gdm and added a 2 gig swapfile and tried the same thing again. Now the system was comatose for 10 minutes.
Then I removed the swapfile and tried again. Coma for about a minute.
Then I re-added the swapfile and tried again. Coma for 3 minutes.
> [memtest] is locking the memory pages as it gets them [...]
I see. I should have guessed that memtest is a bit different from normal applications.
I just made a small application that simply malloc()s some mem and then reads it in a loop, and it had only a minor effect on the overall responsiveness even when using available RAM + 1 GiB.
Still, all desktop linuxes I've seen under high load (I've seen maybe 15 different computers under such conditions, and only a few of those mine) have had problems with responsiveness. Usually when there's some disk I/O involved the overall responsiveness drops to, or close to, uselessness. I've seen this happen e.g. when much of a program using garbage collection has been swapped to disk and it suddenly starts a big GC while some other program does some heavy disk I/O (e.g. copying a big file from one partition to another).
Another problem is vmplayer. Even if I run all vmware-related processes at nice 0 and all audio-related processes at nice -15 I still get skipping sound when whatever is running in vmplayer starts doing something. However, that's probably not linux' fault. (And I haven't seen the same problem with VirtualBox, but VirtualBox OTOH always dies after a few minutes anyway, so I haven't tested it much.)
I should probably make a repeatable test case that I can give people who claim there's something wrong with my h/w. However, I really, really don't have time for that right now. :-(
Anyway, I do think some of Con's feelings are completely justified. I've seen Torvalds and Morton time and again value throughput over all else.
Member since:2007-03-30
Member since:
2005-07-06
> With the latest stable kernel I cannot get the audio
> to skip, even at 100% load.
Try running a vmplayer with something that uses a few hundred megs and lots of I/O. With a load of 6-7 you will get skipping audio no matter how little CPU and I/O your mp3 player requires.
> The only thing that can still ruin my multimedia
> experience is when I run out of RAM but this is not
> Linux's fault.
Sure it is. With the "2.6.20-16-lowlatency #2 SMP PREEMPT" in ubuntu feisty, an Opteron 180, 3 GiB RAM (almost all of which was free) and swaps on 3 different disks I yesterday tried running 7 "nice -n 19 memtest 500M" and immediately when the mouse pointer froze I typed "killall memtest<Enter>", but still the computer was as good as dead for about an hour. Nothing should make the mouse pointer freeze for an hour (or even a few seconds), even if the computer had the world on its shoulders. That a few nice-19 processes accessing a few hundred more megs ram than is available puts it into a deep coma is inexcusable, and it's most certainly Linux' fault.