Date: Tue, 13 Apr 1999 17:48:31 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: jdp@polstra.com, mi@aldan.algebra.com Cc: current@FreeBSD.ORG Subject: Re: cvsup Message-ID: <199904132148.RAA13399@pcnet1.pcnet.com>
next in thread | raw e-mail | index | archive | help
John Polstra wrote: > 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. > Does Modula-3 use libc_r, or does it have it's own user thread support? The recent set of commits to libc_r changed the thread scheduling mechanism to use ITIMER_PROF instead of ITIMER_VIRTUAL. This was to allow for fairer scheduling with I/O bound threads. Dan Eischen eischen@vigrid.com 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?199904132148.RAA13399>