/me sighs. Here it goes again: On Fri, 2006-04-21 at 16:56 +0100, Matt Judge wrote: > I guess you are trying to be a pedant here. Or I over simplified my > explanation. Expanding on your view point, my CPU utilisation would be > 100% all the time, distributed between all the processes currently > running. Guess what? it isn't. Go and learn about kernel scheduling.
The reason why CPU utilization isn't at 100% all all times is because all those threads are blocking on something else and/or sleeping. > I did try replying to the rest of your email, but it was patently clear > that trying to explain how Unix type operating systems work would be > clearly beyond you, so I gave up. All the answers are in my previous > post, please read it and be enlightened. Empirical evidence time. Here comes the clue train... ********** Case 01: 1 CPU-bound thread, nice 0: ********** ( nice -n 0 yes > /dev/null ) & PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 8323 root 25 0 1460 372 312 R 98.3 0.0 0:09.25 yes 8133 root 15 0 152m 20m 6636 S 1.3 2.0 0:15.75 X As you can see, the CPU-bound process immediately chews up all your CPU time (98.3%). ********** Case 02: 1 CPU-bound thread, nice -10: ********** ( nice -n -10 yes > /dev/null ) & PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 8329 root 15 -10 1456 368 312 R 99.4 0.0 0:09.02 yes 8133 root 15 0 152m 20m 6744 S 0.7 2.0 0:17.35 X Chews up your CPU time again, this time on nice -10. System is rather unresponsive, owing to the CPU prioritizing this useless process above all else. ********** Case 03: 1 CPU-bound thread, nice 10: ********** ( nice -n 10 yes > /dev/null ) & PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 8333 root 35 10 1456 368 312 R 98.7 0.0 0:05.32 yes 8133 root 15 0 152m 20m 6744 S 1.0 2.0 0:19.44 X Same results, but system more responsive. ********** Conclusions ********** As you can see, a CPU-bound process immediately tries to eat up as much CPU time as it can get. Niceness just regulates how important we rate this process. And please, stop pulling phrases like "kernel scheduling" out without fulling understanding the context. John Sheu _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
