Memory usage of crunchgenned binary vs shared

[Stephen Borrill <netbsd%precedence.co.uk@localhost>]

In an embedded project, I have kernel with an internal md root. I am then 
using compressed vnd images, one of which includes standard shared 
libraries (e.g. libc). By default, all the standard scripting tools (sh, 
awk, sed, rm, cp, etc.) are all part of the monolithic crunchgenned 
binary. As such they have a vsz of around 2.5MB when running. I've 
noticed that in short memory situations that they are sometimes killed 
causing scripts to fail in odd ways. This lead me to think that 
installing the shared versions in the vnd and symlinking to them might 
save memory.

However, every time I think about the logic of this I come up with a 
different answer :-)

My current belief is that using the shared version will actually make 
things worse. The md block cannot be run in place as they are in a 
read-only place in the kernel memory so they are copied out. This is done 
by block. In a crunchgenned binary the whole binary (and therefore all 
links to it) will therefore be copied once and thus take up 2.5MB of 
memory (over and above the RAM already used by its read-only image in the 
kernel). If the shared version is used, the buffer cache will have the 
whole of libc (which is likely to be there anyway because it'll be used 
by other things) plus the shared binary versions of each individual 
executable. I'm not sure how this maps to per-process memory usage though.

Could any VM experts give me a definitive answer here? :-)

--
Stephen