The Whole is Less than the Sum of the Parts

Done bit more work on the exmap-console tool this week, adding an interactive mode, and a project page with few more details about it.

So, how much memory is really used, and by what, on a Gnome desktop ? Here is a exmap-console snapshot of my machine, restricted to processess that use at least 3MB of virtual memory, and sorted by the memory each process has in sole use; I would really like to know why the gnome-panel needs nearly 9MB of ram to itself, and why gnome-keyboard-applet is approaching 7MB!

(Ups, just noticed that after the refactoring for the interactive mode, it no longer prints to stdout in non-interactive mode; will fix that shortly. In the meantime, use the –log parameter to direct oputput to file, that works just fine).

Just came accross an interesting post on the Beeb about a guy who postulated a system of arithmetic in which it is possible to divide by 0 with impunity. The post there has generated huge, and almost entirely negative, response (I am not too surprised by that). Nevertheless, I really hate to dismissing something just because it is radically different than what I am used to, so I had a brief look at the two original papers by Anderson (here and here; I know, strange place). It became very quickly clear to me that pretty much all the (often derogatory) comments on the Beeb site that ‘disprove’ his proposal miss the mark. Read the rest »

Now and again the p.g.o sees a post about working out how much memory a process, or GNOME as a whole, uses, and about the limitations of the ‘normal’ ways of querying memory usage. In fact, there is a tool which is perfect for this kind of a task: it was written by John Berthels and is called Exmap.

When it comes to analysing memory use, Exmap simply rules: it will tell you how much VM process uses, how much of that is shared (and how well shared), how much is mapped, how much is writeable. If that is not enough for you, Exmap will break down the memory use into the individual executable modules the process has loaded, with the same level of detail as it did for the entire process. Want more? Well, why not have a look how the memory is distributed between module sections? Exmap will let you. Still not happy? You can, providing the module contains the necessary symbol info, have a look at the individual symbols. Exmap simply rocks!

There is, though, a small fly in the ointment — Exmap is a GUI application. This is great if you want to have a look at a process you are running on your desktop. It is not so great if you want to save the results for later, and you are truly skunnered if you need to analyse an embedded system on which running the GUI is out of question. At OpenedHand the latter is our bread and butter, and so the idea of a command line client for exmap was born.

The current version of the command line client will let you get at most of the information the GUI application would, with a level of detail controlled by a handful of command line options. It can send the results either to stdout or a file of your choosing, either in a ‘human-friendly’ (indented) form, or in csv format (so you can load it into your favourite spreadsheet). In addition, it comes with a very simple daemon that allows you to spawn exmap periodically, and log results.

(P.S. To build it from the sourceball, you will need to have the kernel headers for the kernel with which it is to be used; once it builds, you have to load the exmap kernel module before you can run exmap. Oh, and the bugzilla is here.)

I am pleased to announce to the unsuspecting world the release of a first iteration of a lighweight command-line frontend to the Exmap memory analysis tool. It is intended to be used in situations where running the GUI application is not feasible (e.g., on embedded devices), or where the memory data needs to be stored for later analysis.

You can download it here (NB: You will need to have the kernel headers installed to build the kernel module.)

Information on the original Exmap tool can be found here.