Holger Parplies wrote:

> 
>> I suppose if the disk in question is an IDE  that the CPU 
>> has to micro-manage it might make sense to blame the application for the 
>> CPU use even if the kernel is doing it.
> 
> Are you talking about PIO? You really should get your system to use UDMA. ;-)

Even with DMA the CPU has to react to a lot of separate events like the 
positioning commands completing, being ready for the next step, etc. Scsi 
controllers usually take care of that with higher level commands and just tell 
you when they are done.

> No, my point was, the "load average" is an attempt to fit the state of a
> system into one single number (which, as we've agreed, is only good for
> getting a quick impression, nothing more). I'm sure I don't have to tell
> you that a lot of disk activity will make a system more unresponsive than
> a lot of processes competing for the CPU. So why just ignore that fact in
> the single number?

Disk activity on one disk doesn't affect processes using a different disk (not 
with sensible hardware, anyway...) - or not using disks at all, so that may be 
irrelevant.  The number of processes waiting for CPU time is never irrelevant.

> We don't have to look far for a practical example. The original poster had a
> load average of 12 on his system, which fit in with his observation that his
> machine was heavily loaded, as you might say. The single number indicated that
> something was probably not as it should be. Without taking "D" processes into
> account, the load average might have been, say, 0.5. Would that have done the
> real situation more justice? Wasn't it exactly the load average, computed the
> way it is, that pointed at where to look for the problem?

No, what you should have inferred from a high load average is that more CPU's 
would be the solution.

> In what state are processes that are waiting for a page fault to complete?
> They're obviously active (as in "wanting to run"), but not runnable. You'd
> argue that a faster CPU wouldn't help, because they can't run anyway. I'd
> argue that they're part of what is going on (or trying to) on the system.
> Let's just disagree on that, ok?

There's no practical difference between a memmap() waiting on disk and a read() 
waiting on disk.  And the right answer to a lot of processes waiting on the 
same 
disk is normally to spread the things they are waiting to read over a bunch of 
disks so the heads are more likely to already be where you want them - or add a 
bunch of RAM so it is more likely to already be in a buffer somewhere.  
Backuppc 
is just a special case that makes 'more disks' a difficult problem.

>> Yes, the load average in mostly just useful to tell you if a faster CPU 
>> would help, but it isn't even good for that if it counts things that 
>> couldn't use the CPU anyway.
> 
> I never looked at the load average that way. Where I need to make that
> decision, it wouldn't work that way in either case, but I can see that it
> could for some people. I'm not sure that was the original intention of
> whoever thought up the load average, though.

What would you look at to decide that your box needs more CPUs?

-- 
   Les Mikesell
    lesmikesell AT gmail DOT com


------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/