[Xorp-hackers] XORP on memory stringent embedded platform

[Bruce M Simpson]

On Thu, Nov 25, 2004 at 10:58:28AM -0800, Bruce M Simpson wrote:
> On Thu, Nov 25, 2004 at 10:23:06PM +0800, edrt wrote:
> > I guess the main reason is because XORP is written in C++. Does the big image size
> > related to stl/template ? Is there good ways to reduce XORP image size? 

On FreeBSD 4.10-RELEASE the disk footprint is down to 38MB with shared
libraries. I haven't benchmarked the memory footprint yet, having problems
finding a version of Valgrind for FreeBSD 4.x.

FreeBSD's top(1) doesn't have a 'shared' column like Linux's (and such a
column is dubious at best).

It is possible to get something of a feel for how much of the resident
set size is made up by shared pages by inspecting the process map (using
procfs directly, and/or procmap from ports). e.g.

List all XORP PIDs:
	ps auxww | grep xorp | awk '{print $2}'
Determine shared library code pages resident per vm_map_entry:
	procmap <pid> | grep 'r-x' | awk '{print $3}'

then total the returned figures to get an idea of each XORP process's
resident shared library page use.

I'm making inquiries about a tool which might do this better. The problem
is that it's quite invasive - for starters it requires that you know how
the FreeBSD VM is organised. Then you need to be able to look at the
process's vm_map, make a pass over every vm_map_entry and note what the
backing object is. Then pool stats per backing object. In the case of a
shared library this is always a vnode.

This would give us some idea of the reduced in-core size we get from
using shared libraries.

Hopefully this stuff should be in CVS soon.

Regards,
BMS