> If a process consumes 10% of CPU time per second, (re)nicing it will not > make it consume more or less time, thereby making it work faster or slower.
That much is true. However: > Imagine a scenario of an ideal system, with nothing else running and, no > overheads for swapping processes. You have 1 high CPU-bound process(a) > utilising 70% of the CPU time slices/s. It is happy using the CPU > without any interruptions from any other processes. (re)nicing it will > not make it run any faster or slower as there is no other processes to > share the CPU time slices. In this scenario, there is no point to > renicing the process as there is nothing else to share the CPU time with. Under this ideal system, with one CPU-bound process, it would monopolize the processor, i.e. 100% utilization. The only reason why such a single process would _not_ use 100% CPU is if the thread were blocking on something else, e.g. I/O requests or sleeping. > Lets add to this ideal system another process(b). Lets assume that if > this process were on its own, it would utilise 20% of the CPU time slices/s. See above. > Now we have 2 processes which are highly likely to be wanting to use the > CPU at the same time. (re)nicing process(a) ensures the our main > process always has priority to use the CPU and get to use more of it > before the CPU passes control to the other process. This ensures that > process(a) runs smoother - but not faster. Suppose that they were set to equal priority. Then the ideal scheduler _should_ allocate 50% CPU time to each thread. Note right away that this already reduces the "speed" of each process by 50%; as they only get the CPU for half the time, they need twice the realtime to process their tasks. Now, suppose one is prioritized over the other and the split is 75%-25%: the higher-priority thread, having more CPU time, would now indeed run faster than the case in which it had only 50% "rights". > If we were to add yet another process to this system which would, by > itself, utilise 30% of the CPU time slices/s, then this is the only case > where (re)nicing would make a process run faster than it would > otherwise. We would now have a 3 processes trying to grab more time > slices/s than the CPU can provide and all the processes would lag > regardless of how you reniced them. So the overall answer is, I suppose, "it depends". As I said, a highly CPU-bound process will indeed benefit from renicing to a lower priority; however, if the process is speed-limited in some way (in our specific case: srcsds will not exceed a particular framerate), the answer may vary. The point of renicing is to prioritize a process in the case that it does try to grab 100% CPU. Translated to the case of running a game server: if there's not much happening on a particular frame, and the server can process that frame with time to spare (and sleep away), then nicelevels will have a negligible impact on the process. However, in a frame with some heavy action (i.e. a firefight), where the server is strapped for time, a lower nicelevel (and a higher priority) means that the thread can effectively monopolize the CPU. In this case, it does run faster. John Sheu _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
