Plan 9 loader memory consumption

Plan 9 loader memory consumption

[Eric]

> From dhog@lore.plan9.cs.su.oz.au Thu May 29 17:14:12 1997
> X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
> To: 9fans@cse.psu.edu
> Subject: Plan 9 loader memory consumption
> From: David Hogan <dhog@lore.plan9.cs.su.oz.au>
> Date: Fri, 30 May 1997 09:37:55 +1000
> 
> I have been trying to compile the X server and ghostscript 4.03
> at home.  Unfortunately I "only" bought 32M of RAM, and 8l
> tends to use around 29M compiling one of these monsters.
> After deducting 3-4M for kernel and ~3M for kfs, I don't have
> enough RAM to keep 8l in core.  This means it takes about an hour
> to link the X server, and a similarly long time for gs.

Huh?  I had to change MAXSEGMAPSIZE (I think) from 8 to 16 and 
recompile the kernel to eliminate receiving Enovmem whenever 
linking gs or compiling libtiff.a (g3states.h is *huge*).  After 
that, I can compile/link everything in the tree just fine... it thrashes
a little bit, but it never has taken more than a handful of seconds.
I have 32M of memory and a PPro150, running pcdisk, and all patches
have been applied.  I don't have the Xserver sources, so haven't 
tried it.  That was, however, the gs that came with the distribution.  
Is 4.03 from somewhere else or is that in the dist?

I've had no ill effects from changing MAXSEGMAPSIZE.
 
Eric Dorman
eld@mpl.ucsd.edu

Plan 9 loader memory consumption

[David]

I have been trying to compile the X server and ghostscript 4.03
at home.  Unfortunately I "only" bought 32M of RAM, and 8l
tends to use around 29M compiling one of these monsters.
After deducting 3-4M for kernel and ~3M for kfs, I don't have
enough RAM to keep 8l in core.  This means it takes about an hour
to link the X server, and a similarly long time for gs.

As I recall, 8l doesn't use malloc and free; it just allocates
space on the heap and never frees it.  It tends to walk some
fairly large lists multiple times, which adds to the thrashing
behaviour when there isn't enough RAM.  I remember being told
that the justification for this was efficiency; when you have
the RAM, it is a lot faster to avoid the extra overheads of
using a real allocator, or so the argument goes.

I'm starting to wonder if it mightn't be a bad idea to try and
change the way 8l does its allocation, to make compiling
these programs possible on machines which don't have huge
amounts of RAM.  Has anyone else looked at the linker internals
and have an opinion on this?  It's been a while since I looked
in there myself, so I don't have a really good feel for how
much memory is being wasted, or how much locality of reference
there is, or indeed how easy it would be to figure out
what needs to be freed...