[Gllug] Linux distro for small memory system

[Nix]

On 30 Oct 2006, Daniel P. Berrange spake thusly:
> 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,

Um, yes it does.

--- oh, do you mean `big' in the sense of `pixel dimensions' as opposed
to `memory consumption'?

>                                         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

This seems like a job for a PixmapSpy X extension, really. :)

> 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/

Iccccck. I guess *that* could explain the huge pixmap memory consumption
more than slightly!

(... except I also saw it when using galeon, which has its own tabbing
implementation... ah well, galeon is mostly dead now, alas.)

> 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...

Yeah, that seems like a *very* good idea. (This was, after all, the
point of smaps, even if it is nasty to parse, see rants by acahalan
passim.)

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

... oh, dammit, I'm not installing *another* bloody version-control tool
just to get one small program. git, cogito, stgit, subversion, bzr-ng,
cvs, is there no end? (I know I've missed about 80% of the VC tools
currently in use out of that list.)

-- 
`When we are born we have plenty of Hydrogen but as we age our
 Hydrogen pool becomes depleted.'
-------------- next part --------------
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://gllug.org.uk/mailman/listinfo/gllug