neilb@spectrum.cs.unsw.oz.au (Neil Brown) (06/05/91)
I recently started using a new 425 complete with 8meg of ram, 200 megs of disc and a 68040 (running Domain/OS 10.3.4 - psk8). This was replacing my old DN2500 (200 meg disc, 12meg ram Domain/OS 10.3.xx) I expected it to run much more smoothly - but boy was I wrong! Admittedly the new machine has less RAM than the old, but I didn't notice much change when I upgraded the 2500 from 8 to 12 meg. I run X windows (the mit X11r4 borrow mode server) with an emacs, a few xterms and the usual extras. I found that when I was paging through taxt in an emacs window (for instance) that it was noticably faster. But as soon as I moved the focus to another window the disc went wild (presumably paging) and there was a distinct delay (maybe 30 seconds) before I could type in that window. This made the machine just about unusable. As bad as a DN2500 with 4Meg. I have since upgraded to 16 meg (memory 'stolen' from another machine. I'll probably have to give it back soon) and now it is REALLY NICE. Fast, smooth, just what I was after. But we cant afford 16meg for all of our new 425s yet... I had a look at a ps listing and all the processes seem much bigger! e.g. on another 2500 (with 12 meg) the typical process size if a few hundred somethings (K?), with sizes upto 2000 or 3000 being common for large things like xterms. The dm is 2592. USER PID SZ RSS TTY STAT TIME COMMAND sys_pers 23385 2592 52 ? S < 39:59 dm # ps axgu | grep $$ root 2749 896 203 ttyp3 R 0:02 -sh # sleep 30 & ps axgu | grep sleep 2752 root 2752 832 96 ttyp3 S 0:00 sleep 30 On my 425, though, its a different story. Sizes are typically 2000-3000 with 5000-6000 for xterm and 7000 for an emacs. The dm is 10240! (And remember I dont use the DM, I use a borrow mode X server). USER PID SZ RSS TTY STAT TIME COMMAND neilb 108910240 92 ? S < 4:23 dm # ps axgu | grep $$ root 3477 4352 252 ttyp6 R 0:01 -sh # sleep 30 & ps axgu | grep sleep 3493 root 3493 3584 340 ttyp6 S 0:00 sleep 30 Has anyone else had similar experience? Is there any good reason why the processes are SO much bigger? Is there anything I can do to reduce their size and so decrease paging? Or is HP just trying to sell more memory? NeilBrown neilb@cs.unsw.oz.au
krowitz@RICHTER.MIT.EDU (David Krowitz) (06/05/91)
What is *really* disturbing is that not only is the virtual address size (SZ) much larger, but the physical RAM size (RSS) is larger! 340Kb to run "sleep"?! It's no more than a 100 line program! One thing comes to mind ... I think I remember reading (where?) that the segiment size (size of the chunks of memory which the MMU maps into RAM) had been increased from 32Kb with the 68020/68030 MMU's to 256 Kb with the 68040 MMU. Of course, I'm getting old and grey, and I can't be relied upon to remember the exact numbers (or even the correct answer ;-) ). -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
root@ladwp (06/07/91)
NeilBrown writes : >I recently started using a new 425 complete with 8meg of ram, 200 megs >of disc and a 68040 (running Domain/OS 10.3.4 - psk8). >This was replacing my old DN2500 (200 meg disc, 12meg ram Domain/OS 10.3.xx) >I expected it to run much more smoothly - but boy was I wrong! >Admittedly the new machine has less RAM than the old, but I didn't >notice much change when I upgraded the 2500 from 8 to 12 meg. >Has anyone else had similar experience? Is there any good reason why >the processes are SO much bigger? Is there anything I can do to reduce >their size and so decrease paging? Or is HP just trying to sell more memory? We have had a similiar experience with updating a DN3500 to DN5500. It is due to the 68040 processor and I believe its 4K blocks rather then the 1K blocks of the 68030. The 3500 ran okay with 8MB but when the 5500 board was installed its Domain and X window performance was awful, worse then a DN3500 with 4MB. Once we increased the memory to 16 or 24 MB the perfomance was great. Our solution : 16MB of addiational memory for each DN5500 from Clearpoint at a cost of 995 per 8 MB board. Another problem we had with the 040 upgrade was that Interleaf 4 TPS (4.0.66) would not run on the O40 chip. Yesterday Interleaf called and said the patch tapes would arrive next week. Marc Hall elroy.jpl.nasa.gov!ladwp!marc
dbfunk@icaen.uiowa.edu (David B Funk) (06/08/91)
In article <9106051356.AA08687@richter.mit.edu> krowitz@RICHTER.MIT.EDU (David Krowitz) writes: >What is *really* disturbing is that not only is the virtual address >size (SZ) much larger, but the physical RAM size (RSS) is larger! >340Kb to run "sleep"?! It's no more than a 100 line program! > >One thing comes to mind ... I think I remember reading (where?) that >the segiment size (size of the chunks of memory which the MMU maps >into RAM) had been increased from 32Kb with the 68020/68030 MMU's to >256 Kb with the 68040 MMU. Of course, I'm getting old and grey, and >I can't be relied upon to remember the exact numbers (or even the >correct answer ;-) ). > Yes, the sr10.3 release notes state this change. This is because the MMU in the 68040 chip (which is a subset of the 030 MMU) supports only two possible page sizes, 4Kb & 8Kb; thus Apollo was forced to use a larger page size on the 040 machines. As the address translation cache is smaller, they also went to a larger segment size, to reduce cache misses (I think ). From page 1-44 in the sr10.3 release notes: The /bin/ld and /com/bind linkers use new segment and page sizes, as follows: o The segment size has changed from 32 KB to 256 KB. o The page size has changed from 1 KB to 4 KB. Programs linked with the pre-SR10.3 linkers may load slower on a Series 400 workstation. Specifically, the text sections are copied at load time instead of being mapped into memory. This causes a slower load time and allows the possibility of scribbling on text. Note that the page size on the "010/020/030 only" machines (all DNxxx series except DN5500) is still 1Kb. It is only the 040'able machines that use the larger page size (9000/4xx). These changes will result in larger memory allocation granularity, and thus the "growth" of the process size. Dave Funk