Stan Hoeppner wrote:
> Bob Proulx put forth:
> > when otherwise it would be waiting for the disk.  I believe what you
> > are seeing above is the result of being able to compute during that
> > small block on I/O wait for the disk interval.
> 
> That's gotta be a very small iowait interval.  So small, in fact, it
> doesn't show up in top at all.  I've watched top a few times during
> these runs and I never see iowait.

I would expect it to be very small.  So small that you won't see it by
eye when looking at it with top.  Motion pictures run at 24 frames per
second.  That is quite good enough for your eye to see it as
continuous motion.  But to a computer 1/24th of a second is a long
time.  I don't think you will be able to observe this by looking at it
with top and a one second update interval.

> I assumed the gain was simply because, watching top, each convert
> process doesn't actually fully peg the cpu during the entire process
> run life.  Running one or two more processes in parallel with the
> first two simply gives the kernel scheduler the opportunity to run
> another process during those idle ticks.

Uhm...  But that is pretty much exactly what I said!  :-) "Doesn't
actually fully peg the cpu" is because eventually it will need to
block on I/O from the disk.  The process will run until it either
blocks or is interrupted at the end of its timeslice.  Do you propose
other reasons for the process not to "fully peg the cpu" than for I/O
waits?

> There is also the time gap between a process exiting and xargs
> starting up the next one.

But what would be the cause of that gap?  Waiting on disk to load the
executable?  (Actually it should be cached into filesystem buffer
cache and and not have to wait for the disk.)  AFAIK there isn't any
gap there.  (Actually as long as there is another convert process in
memory then the next one will start very quickly by being able to
reuse the same memory code pages.)

> I have no idea how much time that takes.  But all the little bits
> add up in the total execution time of all 35 processes.

Yes.  All of the little bits add up and I believe accounts for the
decrease in total wall-clock time from start to finish.  A small but
measurable value.

And I think we were in agreement about everything else.  :-)

Bob

Attachment: signature.asc
Description: Digital signature

Reply via email to