[Gllug] Linux distro for small memory system

[Daniel P. Berrange]

On Mon, Oct 30, 2006 at 11:59:26PM +0000, Nix wrote:
> 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'?

Opps, my mind was playing tricks on me. The bit that was missing wasn't
getting size data, it was enumerating the Pixmap  ID numbers, to enable
capturing of the raw data.

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

Matthew Alum picked up on the work we were doing in OLPC and very kindly 
wrote a XResQueryClientPixmaps() method for the XRESOURCE extension to 
allow us to enumerate the pixmaps. That at least lets you capture them
periodically by polling, but the actual inline live capture was very
informative because it let us see the hundreds of very short lived 
pixmas which wre being created during ordinary course of rendering GTK
widgets!

https://www.redhat.com/archives/olpc-software/2006-March/msg00032.html

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

I didn't find it very difficult to add parsing of smaps at all really, 
after all this is what perl excells at :-)

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

I started using mercurial because I needed it for my Xen & OLPC work, 
and found it very pleasent to use. Its got a much lower learning overhead
than any of the other distributed SCMs - it wasn't really any harder to
pick up than subversion. You certainly can't say the same for git, bzr,
et all. No tedious dependancy chain of software to pull in like subversion
either, python's all you need !

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/20061031/96cd16c5/attachment.pgp>
-------------- next part --------------
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://gllug.org.uk/mailman/listinfo/gllug