Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423380Ab3FUXmn (ORCPT ); Fri, 21 Jun 2013 19:42:43 -0400 Received: from mail-vb0-f51.google.com ([209.85.212.51]:47114 "EHLO mail-vb0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161536Ab3FUXmm (ORCPT ); Fri, 21 Jun 2013 19:42:42 -0400 MIME-Version: 1.0 Date: Fri, 21 Jun 2013 16:42:41 -0700 Message-ID: Subject: RFC: named anonymous vmas From: Colin Cross To: lkml Cc: Linux-MM , Android Kernel Team , John Stultz Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2153 Lines: 38 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/