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 ktrace. If we had kernel threads and Modula-3 supported them, this wouldn't be a problem. But those are two very big ifs. :-( John --- 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
