On 02Sep2009 17:07, Rick Stevens <ricks@xxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx> I like that line. I hope my boss falls for it. - Chaim Frenkel <chaimf@xxxxxxxx> -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
