Date: Tue, 13 Apr 1999 14:26:53 -0700 (PDT) From: John Polstra <jdp@polstra.com> To: mi@aldan.algebra.com Cc: current@freebsd.org Subject: Re: cvsup Message-ID: <XFMail.990413142653.jdp@polstra.com> In-Reply-To: <199904131914.PAA92766@misha.cisco.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 jdp@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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.990413142653.jdp>