RFC: named anonymous vmas

[Colin Cross]

One of the features of ashmem (drivers/staging/android/ashmem.c) that
hasn't gotten much discussion about moving out of staging is named
anonymous memory.

In Android, ashmem is used for three different features, and most
users of it only care about one feature at a time.  One is volatile
ranges, which John Stultz has been implementing.  The second is
anonymous shareable memory without having a world-writable tmpfs that
untrusted apps could fill with files.  The third and most heavily used
feature within the Android codebase is named anonymous memory, where a
region of anonymous memory can have a name associated with it that
will show up in /proc/pid/maps.  The Dalvik VM likes to use this
feature extensively, even for memory that will never be shared and
could easily be allocated using an anonymous mmap, and even malloc has
used it in the past.  It provides an easy way to collate memory used
for different purposes across multiple processes, which Android uses
for its "dumpsys meminfo" and "librank" tools to determine how much
memory is used for java heaps, JIT caches, native mallocs, etc.

I'd like to add this feature for anonymous mmap memory.  I propose
adding an madvise2(unsigned long start, size_t len_in, int behavior,
void *ptr, size_t size) syscall and a new MADV_NAME behavior, which
treats ptr as a string of length size.  The string would be copied
somewhere reusable in the kernel, or reused if it already exists, and
the kernel address of the string would get stashed in a new field in
struct vm_area_struct.  Adjacent vmas would only get merged if the
name pointer matched, and naming part of a mapping would split the
mapping.  show_map_vma would print the name only if none of the other
existing names rules match.

Any comments as I start implementing it?  Is there any reason to allow
naming a file-backed mapping and showing it alongside the file name in
/proc/pid/maps?
--
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/