[Gllug] Linux distro for small memory system

[Daniel P. Berrange]

On Mon, Oct 30, 2006 at 07:23:05PM +0000, Richard Jones wrote:
> On Mon, Oct 30, 2006 at 03:21:46PM +0800, Richard Cohen wrote:
> > There is a fascination within the community with repurposing old
> > hardware - old, *obselete* hardware.  A machine with 64MB of RAM is
> > perfectly capable of running as a headless - or at least X-less -
> > machine, but it's simply not suitable for use as an interactive
> > graphical desktop machine, running anything like current software.
> 
> Richard, you are right: It has been brought home to me all the more by
> trying to get this laptop (actually two laptops) working again.

[snip]

> A lot of the problem is the ever present "top" command.  Unfortunately
> "top" does _not_ give an accurate representation of the total
> resources used by an application (let alone set of applications such
> as "the GNOME desktop").  For example, we wrote some analysis tools
> which top reports as using 40 GB of RAM - in fact they mmap a single
> huge file and then use tiny bits of it.  They are not resource hungry.
> On the other hand an application which forgets about its pixmaps
> inside the X server can look quite slimline, when in fact it's a major
> offender.

Yes, using top to gauge memory usage of applications is a complete
and utter waste of time. It doesn't tell you about server side resources
used, it doesn't tell you that 3.5 GB of that 4 G is not even mapped by
the OS (& likely never will be), it doesn't tell you that another 300 MB
of .so's is shared by every X application, etc, etc. Useless. Don't even
bother looking at top beyond identifying a potentially suspect app.

> I think Dan Berrage has been writing/using some such tools for the One
> Laptop Per Child project ...  What's really needed is something as
> easy and ubiquitous as "top", but accurate.

Yes, I wrote two tools for OLPC. The first takes a PID and formats
the contents of /proc/PID/maps intoa  more friendly format. So you
can at least get a breakdown of the different types of objects mapped
in the process (eg, .so's, locale info, heap, etc) at a fairly
coarse level. It more useful than top, because it lets you see that
60 MB is just the locale info (shared by every proess using libc),
for example.

The second tool is a LD_PRELOAD hack which captures the raw pixmaps
created by an X application & saves them out as tiff files. There is
xrestop which shows how many pixmaps are being created by apps, but
this doesn't tell you how big they are, or what's stored in them.
Being able to actually view the image data was a great help, as was
being able to capture the stack trace of the code creating the pixmap

With these two tools we did some analysis on Epiphany and found that
there was indeed a memory leak in the pixmap caching code when you
had > 1 tab open. This is now fixed in upstream mozilla codebase I
believe. The test data we used at least showed there was no other
noticable memory leak in the code & its caches were being popiulated
and purged as intended (although it does delibrately use alot of RAM,
which is a quesitonable design decision, but not a leak). A summary
was here:

  http://berrange.com/personal/diary/2006/03/epiphany-memory-use-analysis
  http://people.redhat.com/berrange/olpc/performance/epiphany/

I've  since done some more work on the tool for analysing process
memory maps, so that it uses /proc/PID/smaps instead. This lets us
actually track on a per-map basis the amount of RAM which is shared
vs private, and clean vs dirty. With this we can get really useful
info about just where RAM is going. The newer code is here...

  http://hg.berrange.com/tools/mem-monitor--devel 

Regards,
Dan,
-- 
|=-            GPG key: http://www.berrange.com/~dan/gpgkey.txt       -=|
|=-       Perl modules: http://search.cpan.org/~danberr/              -=|
|=-           Projects: http://freshmeat.net/~danielpb/               -=|
|=-   berrange at redhat.com  -  Daniel Berrange  -  dan at berrange.com    -=|
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: Digital signature
URL: <http://mailman.lug.org.uk/pipermail/gllug/attachments/20061030/587f80f4/attachment.pgp>
-------------- next part --------------
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://gllug.org.uk/mailman/listinfo/gllug