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 eisc...@vigrid.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
