Re: [PATCH 12/13] maps: Add /proc/pid/pagemap interface

[Matt Mackall <mpm@selenic.com>]

On Wed, Apr 04, 2007 at 03:18:41PM +0400, Nikita Danilov wrote:
> This pushes binary data to the user space. Wasn't /proc supposed to be
> ascii-based to avoid compatibility problems (e.g., size of unsigned long
> changing, endianness, etc.)?

Most of what's in /proc is ASCII, true. But there are notable
exceptions - kcore, auxv, mem. This is just another window into memory
like kcore and mem. It's also a fairly big window. To examine a 1G
mapping, you need to read 1M of data.

ASCII would be rather ugly here. It's important that the interface be
seekable so that you can skip over wide ranges of data with no maps.
So all the elements would have to be nice fixed sizes. That'd mean 16
hex digits plus a space/newline. So to figure out what's at b7f81000,
I'd have to divide by 4096 (I already have to know the page size),
then multiply by 17, getting c37791. And then I'd have to copy more
than 2x the data in byte-wide chunks due to alignment concerns.

With the extra translation on both ends, the expanded data size, and
the alignment issues, this probably just got 10x-20x slower. Which
means taking a snapshot of a typical system and doing any sort of live
display just got a hell of a lot more impractical.

Now I could adjust these to only export u64s in some preferred
endianness. But given I already need details like the page size to
make any sense of it, it seems unnecessary. Also, the PFNs are fairly
opaque unless you're attempting to correlate them with /proc/kpagemap.

--
Mathematics is the supreme nostalgia of our time.