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 <[email protected]>
MontaVista Software, Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
