Re: new procfs memory analysis feature

[Joe Green]

Albert Cahalan wrote:
> David Singleton writes:
>
> > Add variation of /proc/PID/smaps called /proc/PID/pagemaps.
> > Shows reference counts for individual pages instead of aggregate totals.
> > Allows more detailed memory usage information for memory analysis tools.
> > An example of the output shows the shared text VMA for ld.so and
> > the share depths of the pages in the VMA.
> >
> > a7f4b000-a7f65000 r-xp 00000000 00:0d 19185826   /lib/ld-2.5.90.so
> >  11 11 11 11 11 11 11 11 11 13 13 13 13 13 13 13 8 8 8 13 13 13 13 13 
> > 13 13
>
> Arrrgh! Not another ghastly maps file!
>
> Now we have /proc/*/smaps, which should make decent programmers cry.

Yes, that's what we based this implementation on.  :)

> Along the way, nobody bothered to add support for describing the
> page size (IMHO your format ***severely*** needs this)

Since the map size and an entry for each page is given, it's possible to 
figure out the page size, assuming each map uses only a single page 
size.  But adding the page size would be reasonable.

> There can be a million pages in a mapping for a 32-bit process.
> If my guess (since you too failed to document your format) is right,
> you propose to have one decimal value per page.

Yes, that's right.  We considered using repeat counts for sequences 
pages with the same reference count (quite common), but it hasn't been 
necessary in our application (see below).

> In other words, the lines of this file can be megabytes long without 
> even getting
> to the issue of 64-bit hardware. This is no text file!
>
> How about a proper system call?

Our use for this is to optimize memory usage on very small embedded 
systems, so the number of pages hasn't been a problem.

For the same reason, not needing a special program on the target system 
to read the data is an advantage, because each extra program needed adds 
to the footprint problem.

The data is taken off the target and interpreted on another system, 
which often is of a different architecture, so the portable text format 
is useful also.

This isn't mean to say your arguments aren't important, I'm just 
explaining why this implementation is useful for us.


--
Joe Green <jgreen@xxxxxxxxxx>
MontaVista Software, Inc.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/