Question on shredding a terebyte drive

[Cameron Simpson]

On 02Sep2009 17:07, Rick Stevens <ricks at 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 a
| 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.

Cheers,
-- 
Cameron Simpson <cs at zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

This is not a bug. It's just the way it works, and makes perfect sense.
        - Tom Christiansen <tchrist at jhereg.perl.com>
I like that line. I hope my boss falls for it.
        - Chaim Frenkel <chaimf at cris.com>