On Wed, Mar 30, 2005, Yedidyah Bar-David wrote about "Re: high load ?":
> 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.
As other people already pointed out on this thread, processes that are in
the D (uninterruptable sleep) state are counted towards the load, and why
many people are puzzled by this behavior, it is exactly the "problem" that
you suggestest which explains why this count is logical.
When a process is waiting for a page it needs to be swapped in, it sleeps in
the D state (I can explain why, if anyone is interested). If several
processes are waiting for pages in the same time, you'll have several
processes in the D state. All this can bring a heavily-paging ("thrashing")
system to report a "load average" much higher with one.
The "load average" in Unix tradition is the number of processes which want
to run now (or on average). Only one (or a few, on SMPs) can run at one time
but several may want to run. Processes in the "R" state (ready to consume
CPU) obviously need to be counted. But processes that have pages swapped in
at the moment also NEED to be counted. After all, these proceses want to
run now too - a paging operation always happens as a result of some memory
access activity in the process, something which was supposed to be satisfied
immediately but couldn't.
Unfortunately, crappy NFS implementations and the like are notorious for
leaving processes in the D state for very long times. This has much worse
effects than making the load average "wrong" - it also means you can't
kill these processes, wasting the memory (or rather swap) they use, and
leaving whatever resources they used (files, filesystems, devices, sockets,
etc.) locked for ever. This is what people referred to as "bugs in the
kernel", and they are indeed bugs.
> 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.
This is a correct observation, and I don't have a solution on how to
measure the "interactive responsiveness" you're after.
Note that for some types of users, the load average, in the traditional
sense, is still what matters. Consider users that run lengthy computations -
scientists, artists doing raytracing or animation, or even video rippers
or whatever. If the load level is 1 (one process is already running all
the time), then their task will run at half speed. This will definitely
bother them.
Obviously, all this has most relevance on shared machines. On your own personal
machine, you normally avoid bothering yourself, and you don't need to look
at the load level to know if you're running two things at the same time.
--
Nadav Har'El | Wednesday, Mar 30 2005, 19 Adar II 5765
[EMAIL PROTECTED] |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |Cats know what we feel. They don't care,
http://nadav.harel.org.il |but they know.
=================================================================
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]
