earl@mips.UUCP (Earl Killian) (09/18/87)
In article <2473@xanth.UUCP>, kent@xanth.UUCP (Kent Paul Dolan) writes: > Second, another correspondent noted that in ten million process activations > on his system, 98% took less than two seconds of cpu time. This means that > loading them was a significant fraction of all the work done in executing > them. It depends. The realtime to vfork/exec something on my machine is about 0.014s, or 0.7% of 2s. So the data needs to be more complete to make this conclusion (like how many of them were < 0.1s, where the loading is 10% of the time). Also be careful not to assume that because 98% of the commands executed in < 2s that most of the work that a machine does is in such commands. More complete data is necessary to make that conclusion as well. The other 2% might execute for a long time...
hammond@faline.bellcore.com (Rich A. Hammond) (09/19/87)
In article <> earl@mips.UUCP (Earl Killian) writes: >In article <2473@xanth.UUCP>, kent@xanth.UUCP (Kent Paul Dolan) writes: > >> Second, another correspondent noted that in ten million process activations >> on his system, 98% took less than two seconds of cpu time. This means that >> loading them was a significant fraction of all the work done in executing >> them. I'm skeptical about concluding that the processes took much work to load. The process activations are concentrated from 10AM to 6PM with a dip around noon. I'm willing to bet that the common commands might have already been in main memory or buffer cache. >It depends. The realtime to vfork/exec something on my machine is ... The relevant # is how long vfork takes on 11/780's, where the jobs ran. >Also be careful not to assume that because 98% of the commands >executed in < 2s that most of the work that a machine does is in such >commands. More complete data is necessary to make that conclusion as >well. The other 2% might execute for a long time... Indeed they did, about 2/3 of 1% of the commands used up 66% of the CPU resoures. BUT, this # was cited in response to a question about improving the UNIX filesystem performance because "A large proportion of all jobs are I/O bound" In fact, our observation is that a very few jobs used up most of the CPU, and they did very little I/O per CPU hour. I suspect this is still true today, although we have 8650's, Convex, CCI, Pyramids and Alliants instead of 11/780's. If I do a vmstat on the Convex, I typically see: user 98% sys 2% idle 0%, hardly an I/O bound situation. Rich Hammond hammond@bellcore.com
dwc@homxc.UUCP (D.CHEN) (09/21/87)
> > > Second, another correspondent noted that in ten million process activations > > on his system, 98% took less than two seconds of cpu time. This means that > > loading them was a significant fraction of all the work done in executing > > them. > > It depends. The realtime to vfork/exec something on my machine is > about 0.014s, or 0.7% of 2s. So the data needs to be more complete to > make this conclusion (like how many of them were < 0.1s, where the > loading is 10% of the time). > i would think that this time does not include the time to demand load the pages needed to generate a "prompt" or any such thing that the user is waiting for. danny chen homxc!dwc
jfh@killer.UUCP (John Haugh) (09/25/87)
(Forget vfork() and how fast it is. When AT&T adds it to System 5, then I'll care about it. ;-) I don't know how valid of a statement this is, but I have noticed that to fork() a small program can often take as long as it takes to fork() one twice as large (just as long being one of those subjective things ...) I benchmarked kernels at my last emoployer and noticed that even the big machines we tested (uVax, Plexus P/60's & P/75's, etc) didn't get past 40 or 50 forks per second. The little programs seem to cost more than the bigger ones in terms of forkability ... Just rambling on ... - John. -- John F. Haugh II HECI Exploration Co. Inc. UUCP: ...!ihnp4!killer!jfh 11910 Greenville Ave, Suite 600 "Don't Have an Oil Well?" Dallas, TX. 75243 " ... Then Buy One!" (214) 231-0993
bruce@stride.Stride.COM (Bruce Robertson) (10/05/87)
In article <1634@killer.UUCP> jfh@killer.UUCP (John Haugh) writes: > >I benchmarked kernels at my last emoployer and noticed that even the big >machines we tested (uVax, Plexus P/60's & P/75's, etc) didn't get past >40 or 50 forks per second. The little programs seem to cost more than >the bigger ones in terms of forkability ... That's odd, my Stride 600 Series (68020-based, System V kernel with the copy-on-write version of fork) does just under 100 forks per second. Even my Stride 400 Series (same kernel, 68010-based) does 48 forks per second. -- Bruce Robertson bruce@stride.Stride.COM cbosgd!utah-cs!utah-gr!stride!bruce