Path: utzoo!utgpu!watserv1!watmath!att!tut.cis.ohio-state.edu!cs.utexas.edu!execu!sequoia!rpp386!jfh From: jfh@rpp386.cactus.org (John F Haugh II) Newsgroups: comp.bugs.sys5 Subject: Re: Shell Scripts v. Command Options Message-ID: <18966@rpp386.cactus.org> Date: 19 Jan 91 19:56:32 GMT References: <18946@rpp386.cactus.org> <1249:Jan1811:37:3991@kramden.acf.nyu.edu> <18959@rpp386.cactus.org> <19394:Jan1917:08:2691@kramden.acf.nyu.edu> Reply-To: jfh@rpp386.cactus.org (John F Haugh II) Organization: Lone Star Cafe and BBS Service Lines: 84 X-Clever-Slogan: Recycle or Die. In article <19394:Jan1917:08:2691@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <18959@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: >> Had you looked at the test data you would see that the CPU time is >> actually spent in the kernel executing code. > >Apparently the system is idle in your tests; many if not most schedulers >will add disk wait time to the system time of the current process. There was no disk wait time, nor did there need to be. You are missing something very crucial here - if the system were idle and I hadn't consumed all available disk buffers, then there would be no physical I/O anyway since the blocks come straight out of the buffer pool. On the other hand, if the scheduler DID charge for disk-wait time, you would have the sum of all executing commands system time higher than the total wall clock time and that is just plain wrong. Normally the "current process" is the system itself or the "idle" process. But in most cases I've seen since v7, there is no accounting for the time - no process see the ticks in their accounting structure. You can verify this with the "crash" command. Finally, there was no need for disk I/O at all since I had not run out of physical memory and did not need to page out or read from the file system - I executed no new commands in the original fork/(exit|wait) scenario. Besides, I'm sitting right next to the drive which make an incredible racket, so I would have heard them go clickity-click-clack if there were any I/O. A counter-proof would be to execute multiple copies of that test at the same time. If the total time remained constant for increasing numbers of simultanous executions of the test case, you would be proven correct. However, I have done exactly this test at past jobs and it has demonstrated that the fork() call does not overlap time well. It really is just a very CPU intensive call. People will point out that it is very wasteful, and I agree - I also agree that fork() should be fixed rather than avoided, but given that the vendors REFUSE to make fork() faster, I don't see any real option but to avoid it. -- Script is typescript, started Sat Jan 19 13:51:45 1991 rpp386-> cat fork.c main () { int i; for (i = 0;i < 100;i++) if (fork ()) wait (0); else _exit (0); } rpp386-> cc -o fork fork.c fork.c rpp386-> timex ./fork execution complete, exit code = 1 real 1.31 user 0.00 sys 1.23 rpp386-> cat fork.sh ./fork & ./fork & ./fork & ./fork & ./fork & wait rpp386-> timex /bin/sh fork.sh execution complete real 6.93 user 0.05 sys 6.36 rpp386-> Script done Sat Jan 19 13:52:24 1991 -- Doing the math, % calc 6.93 / 5 1.386 % calc 6.36 / 5 1.272 Which you can see is pretty damned close to 1.31 and 1.23 in the first case. -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org "While you are here, your wives and girlfriends are dating handsome American movie and TV stars. Stars like Tom Selleck, Bruce Willis, and Bart Simpson."