On 02Sep2009 17:07, Rick Stevens <ricks(a)nerd.com> wrote:
| Dean S. Messing wrote:
| > 4) I don't know if the fact that the process runing at 100% of one CPU
| > means it is compute bound. Looking at the disk I/O meter in
| > gkrellm I see bursts of writes followed by intervals of no
| > transfer. I know that magnetic reorientation requires some time
| > to "set" and that may be why the delays are there. Or it may be
| > compute bound.
| Run "top" and you may find that the shred process is in a "D" state
| lot of the time. That means it's in an I/O wait state, waiting on the
| drive to complete some operation.
During this time it should be consuming _no_ CPU.
| A "D" state can suck up a lot of CPU.
It should not. Historically, processes in D state have been counted
towards the load average, because D states are normally very brief and
the process will be back on the run queue Real Soon Now.
So while D state processes run up your load average, purely for purposes
of having that number indicated better how "busy" your system is, a
process in D state does _not_ suck up CPU unless it's flickering in and
out of D state so fast that the OS housekeeping becomes expensive.
Cameron Simpson <cs(a)zip.com.au> DoD#743
This is not a bug. It's just the way it works, and makes perfect sense.
- Tom Christiansen <tchrist(a)jhereg.perl.com>
I like that line. I hope my boss falls for it.
- Chaim Frenkel <chaimf(a)cris.com>