Is it just me...?

...or does Linux handle process priorities like ass? I've noticed many times multitasking behaves weird and sub-par compared to Windows. For two times I've had to reset my fucking workstation because some regular process (think Kate (!)) would take 100% CPU somehow and I couldn't even get to switch to a text terminal to kill it, Bash wouldn't start. The mouse cursor is sluggish when the system is busy; X screensavers in KDE's Control Panel preview box behave really weird (sometimes sluggish, sometimes fine), simple commands launched from a terminal sometimes deal a huge impact on applications, browsers get terribly slow and sluggish when JavaScript marquees present (I've noticed FreeType is slow as hell too), and so on.

I've found Windows 2000 far more smooth and better respecting process priorities.

KDE, LOL.

I have exactly none of the problems you describe. Which distro are you using?

Check a) whether you have dma enable(hdparm -i /dev/hda)
b) whether you have the right video driver enabled in your xorg.conf(or xf86.conf)
c) Check your kernel settings, I mean, are you using some lameass generic kernel or did you compile a custom one(which is the best option ofcourse) It doesn't matter what distro you're using, Linux is Linux(ofcourse package version can differ) but you can finetune any distro to your needs.

>>4
I find painting flames on the side of your case and adding a spoiler help alot too.

>>5
I can't see how that would help. Mind elaborating?

>>6
No, if it's not obvious to you then you must be retarded.

>>6
It makes my Honda Civic go faster, can't see why it shouldn't work for my computer.

You ask people to help you out, you don't know shit about Linux(my guess is you don't shit about operating systems in general, otherwise you would find it pretty obvious why one would recompile his kernel, but then you start questioning why one would check his xorg.conf or recompile his kernel, I mean...

If you wanna learn about linux and OSS in the first place you wouldn't have posted this stupid thread in the first place, you would tried to solve it yourself, but no..

>>9
What.

Nevermind, solved the problem yet ?

>>8
You got a Japanese car? Cool! I want one too!

But... I can not see why things that make a car go faster (velocity, or actually grip, which confers faster lap times) would make a computer go any faster (instructions per second), I mean, it's immobile.

>>3
SuSE Linux 10, also noticed the same with SuSE 9

>>4
a) Yup, UltraDMA is enabled
b) Yeah, I've verified it too
c) I don't have the necessary knowledge to compile the Linux kernel and tune it to my needs, nor I think I should; Windows comes with a pretty low standard to run on all processors since 486s and it runs smoothly

>>9
Wait, I'm >>1 but I'm not >>5 or >>7
I don't think I don't know shit, yet I don't see why I should compile the kernel of my OS. You must belong to the compile religion.

>>11
No, I didn't solve the problem nor I was expecting a quick solution to it (if it were simple, I'd have found it myself); I have been noticing this for months, and I wanted to share this and see if others have noticed the same.


For example, when tar+bzip2ing a bunch of files I'm working on. How on Earth will that decrease performance in, for example, my web browser, to the point I can actually notice (and quite obviously) it's happening? You couldn't tell the difference in Windows, even if all processes run with Normal priority class.

Ah now bzipping can bog down your system because it's an IO intensive process. I notice it most when unpacking a large archive. You might be able to adjust its niceness to avoid getting in the way of your activities.

>>14
Yet doing that with the same program (or another archiver for that matter) in Windows will not be noticeable unless the archiver has a higher priority class than other applications... That's what I mean when say I feel Linux handles multitaking worse.

>>15
See the bit where I suggested you renice it? DID YOU?

Problems with tar+bzip2ing, eh? Maybe try choosing another IO scheduler? I really don't know how much they really change, but maybe you've got one that's suited for a server while one that's better suited for a desktop might be a better idea.

Whatever the case is, nothing is worse than a precompiled kernel, not even Windows.

>>16
See the bit where I said I don't need to hand priorize processes in NT and I was wondering why do I have to in Linux?

>>17
Now this is more interesting advice. I'll keep it in mind if I ever feel like messing with that.

BTW, how come one single Windows 2000 kernel works great for all processors, old and new machines, servers and workstations, and a resourceful company like SuSE/Novell can't get one Linux kernel that will behave properly everywhere?