Re: RFC: named anonymous vmas

[Kyungmin Park]

On Sat, Jun 22, 2013 at 8:42 AM, Colin Cross <ccross@xxxxxxxxxx> wrote:
> 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

Good to know it. I didn't know ashmem provides these features.
we are also discussing these requirement internally. and study how to
show who request these anon memory and which callback is used for it.

> 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.
Same requirement for app developers. they want to know what's the
meaning these anon memory is allocated and how to find out these anon
memory is allocated at their codes.
>
> 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.
Do you want to create new syscall? can it use current madvise and only
allow this feature at linux only?
As you know it's just hint and it doesn't break existing memory behaviors.
>
> 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?
>

Thank you,
Kyungmin Park
--
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/