Path: utzoo!attcan!uunet!husc6!bloom-beacon!mit-eddie!ll-xn!ames!elroy!cit-vax!ucla-cs!minnie!kennel From: kennel@minnie.cognet.ucla.edu (Matthew Kennel) Newsgroups: comp.sys.apollo Subject: Re: Open Dialogue - please summarize Message-ID: <14021@shemp.CS.UCLA.EDU> Date: 29 Jun 88 23:49:32 GMT Sender: news@CS.UCLA.EDU Organization: none Lines: 50 I have a question and perhaps a problem. I'm running Domain/IX on a DN4000 workstation. When I'm in BSD4.2 (or some reasonable facsimile thereof) I do a 'ps -v' to look at the memory that my processes take up. I'm specifically interested in the 'SIZE' field. It appears that according to the man page SIZE is the total virtual size of a process, i.e. the amount of virtual memory the process takes up whether on disk or in real RAM. Now, I change over to SYS5 and do a 'ps -l'. According to _this_ man page the 'SZ' field refers to : "The size, in blocks, of the core image of the process." But the numbers are ALWAYS the same! So which is it? Now here is my problem: I'm running a BIG lisp image (~11M) on disk. Whenever I use it, I notice that its 'SIZE' never goes above some number like 4288, and proceeds to page fault very heavily. There appears to be 2 possibilities: 1) 'SIZE' == virtual memory. But I can't believe that an 11M saved image would only give itself 4M of virtual memory! 2) 'SIZE' = real memory. I have 8M on my machine and so I would think that I could get more than 4M of real memory for lisp. (BTW no other big processes were running, just the normal daemons and a csh) And I also ran it on another machine that was practically identical, except that it had 16M of RAM. Again, SIZE went up to some number around 4000 and I got tons of page faults. As a test, I wrote a C program that malloc's a whole lot of memory, and its SIZE field was way up in the 8000s. It appears that somehow LISP limits the amount of real memory it will take up. I want to increase that limit! I've tried playing around with the LISP variables LISP_DYNAMIC_LIMIT and LISP_RESERVED_LIMIT or whatever and these seem to have no effect on whatever 'SIZE' is, but only seem to control the partition of LISP's total memory among its internal structures. If you have any ideas, please e-mail to kennel@cognet.ucla.edu Much thanks, Matt Kennel