Mikhail Teterin wrote:

> However, the CPU is not 100% busy, and the cvsup is still slow to
> update sometimes... Updating it does not need anything but the CPU,
> does it (on the local display)?

Correct.  I have not tried to analyze where the delays come from.
But I do have a guess.

CVSup uses user-level threads.  If a thread gets blocked waiting for
network I/O, the thread scheduler can run a different thread while it
is waiting.  A subsequent call to select() will inform the scheduler
when the I/O can be resumed.

But that isn't possible for disk I/O.  If you call read() or write()
on a disk file, it never returns EAGAIN.  It always blocks in the
kernel, non-interruptible by signals.  When that happens, the process
is blocked and it can't run any other threads or do anything else
at all until the read/write call has completed.  Since CVSup is so
disk-intensive, I suspect it is wasting a lot of time blocked in those
calls.  An interested person could probably confirm or deny that using

If we had kernel threads and Modula-3 supported them, this wouldn't be
a problem.  But those are two very big ifs. :-(

  John Polstra                                               j...@polstra.com
  John D. Polstra & Co., Inc.                        Seattle, Washington USA
  "Self-interest is the aphrodisiac of belief."           -- James V. DeLong

To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Reply via email to