tytso@athena.mit.edu (Theodore Y. Ts'o) (01/30/89)
The following is a truncated down copy of a ps done on the our NeXT: USER PID %CPU %MEM VSIZE RSIZE TT STAT TIME COMMAND tytso 149 1.0 3.2 16.3M 264K p0 S 0:21 -bin/tcsh (tcsh) root 2193 0.5 2.6 16.2M 216K p0 R 0:00 ps augx root 70 0.1 1.1 5.84M 88K ? S 0:32 /etc/nmserver root 3 0.0 0.0 584K 0K ? SW 0:00 /etc/mach_init -xx root 2 0.0 0.0 0K 0K ? SW 0:00 (exception_hdlr) me 2174 0.0 0.0 816K 0K ? SW 0:00 -tcsh (tcsh) root 1 0.0 0.0 600K 0K ? SW 0:00 init -xx root 90 0.0 0.0 792K 0K ? SW 0:10 /etc/inetd Why are processes so huge?!? I started a /bin/sh, and it was even larger than my tcsh --- 18 Megs!!!! What's going on? Even on RISC machine those sizes are incredibly large..... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Theodore Ts'o mit-eddie!mit-athena!tytso 3 Ames St., Cambridge, MA 02139 tytso@athena.mit.edu If it's for real, it isn't!
avie@wb1.cs.cmu.edu (Avadis Tevanian) (02/03/89)
In article <9013@bloom-beacon.MIT.EDU> tytso@athena.mit.edu (Theodore Y. Ts'o) writes: >The following is a truncated down copy of a ps done on the our NeXT: > >USER PID %CPU %MEM VSIZE RSIZE TT STAT TIME COMMAND >tytso 149 1.0 3.2 16.3M 264K p0 S 0:21 -bin/tcsh (tcsh) >me 2174 0.0 0.0 816K 0K ? SW 0:00 -tcsh (tcsh) > >Why are processes so huge?!? The VSIZE field represents the virtual size of the task. The large sizes are often due to the fact that Mach allocates stacks at application launch time. (It can do this because of the lazy evaluation of the VM system). A bin/tcsh at 16meg is probably because the stack limit was set to 16meg. /bin/sh allocates 2meg to overcome a problem with restarting instructions on a 68030 (/bin/sh used to handle SIGSEGV's to extend its break region, that doesn't work on a 68030). -- Avadis Tevanian, Jr. (Avie) Chief Operating System Scientist NeXT, Inc. avie@cs.cmu.edu or avie@NeXT.com --
dupuy@cs.cs.columbia.edu (Alexander Dupuy) (02/08/89)
In article <4180@pt.cs.cmu.edu> avie@wb1.cs.cmu.edu (Avadis Tevanian) writes: > > /bin/sh allocates 2meg to overcome a problem with restarting instructions > on a 68030 (/bin/sh used to handle SIGSEGV's to extend its break region, > that doesn't work on a 68030). Am I reading this right? I remember that there was a problem with the 68000 (the original) being unable to restart some instructions - that was why you needed a 68010, which allowed you to restart all instructions, if you wanted to have a demand-paged virtual memory system. Is it really true that the 68030 has the same proble the 68000 had? Doesn't sound like progress to me... Please respond by mail - I don't read these groups very regularly. @alex -- -- inet: dupuy@cs.columbia.edu uucp: ...!rutgers!cs.columbia.edu!dupuy