From owner-freebsd-current Tue Apr 13 14:29:17 1999 Delivered-To: freebsd-current@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id D012E1508F for ; Tue, 13 Apr 1999 14:29:13 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.1) with ESMTP id OAA17572; Tue, 13 Apr 1999 14:26:53 -0700 (PDT) (envelope-from jdp@polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id OAA75285; Tue, 13 Apr 1999 14:26:53 -0700 (PDT) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199904131914.PAA92766@misha.cisco.com> Date: Tue, 13 Apr 1999 14:26:53 -0700 (PDT) Organization: Polstra & Co., Inc. From: John Polstra To: mi@aldan.algebra.com Subject: Re: cvsup Cc: current@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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