On Wed, Mar 30, 2005 at 09:25:29AM +0200, Shachar Shemesh wrote: > guy keren wrote: > [snip] > > Processes should never spend too much time in the "D" state. The very > fact that certain activities mean you are almost guaranteed to see > processes in the "D" state means there are bugs in the kernel. However, > these are unrelated to system load. A process in the "D" state is not > consuming CPU, and will not prevent my shell from getting to the top of > the "ready" queue and getting the CPU. "D" state processes distort the > load average number.
Agreed. I know there are people that patch their kernels to not count D state processes in the load average. [snip] > You may have to tweak the numbers a bit, but it seems about right. A > different question is whether, under this scenario, the load average is > still the right metric to look at? I think it is. If the load average is > 2, my shell still have quite a queue to wait for being actively > processed, and the responsiveness will depend on the time slices alloted > to each process. This is so only if you have load only on the CPU. If, for example, you only have one process running, but which does a lot of paging, your load average will be <=1, but the responsiveness will be quite bad, as your shell will probably be paged out when you press a key. OTOH, today's CPU are very fast, and in most cases, if you run a few 'for (;;);' in the background, an interactive shell user won't notice, while the load average will equal the number of such loops. Much more annoying for our own users is amd mounts that sometimes take a lot of time or stuck. I know this isn't kernel-related, but it does hurt a lot responsiveness. I personally do not know any single number that can tell on unix what the expected responsiveness is. -- Didi ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
