> The run queue (high load) issue seems the kind of thing that could be an issue with the client kernel Under Linux, a high load roughly tells you that the sys

> The run queue (high load) issue seems the kind of thing that could be an issue with the client kernel Under Linux, a high load roughly tells you that the system is bottlenecked on something, where that something isn't necessarily CPU cycles. If your system is bottlenecked on pending NFS requests, the load will be high, and that's not the result of any kernel shortcomings (unless one blames blocking file I/O on the difficulty of correct use of exposed async/non-blocking file I/O syscalls). The high load average is a matter of accounting[0]. Under Linux, tasks (threads) in I/O wait are considered runnable, although they're not scheduled for CPU time. Other OSes (e.g. most Unix descendants, probably WinNT) make other accounting decisions, but either way, tasks blocked on I/O don't affect CPU-bound tasks. The Linux manner of load accounting isn't what I would have implemented at first, but if you're going to collapse system load into a single metric, then it seems best to include blocked tasks. If you've got high load, then it's time to dig deeper into more nuanced metrics anyway, so in retrospect, I agree with Linux's more holistic load accounting. [0] https://en.wikipedia.org/wiki/Load_(computing)#Unix-style_load_calculation https://en.wikipedia.org/wiki/Load_(computing)#Unix-style_lo...