On Mon, 14 Oct 2013 18:31:17 -0700 Colin Cross <ccross@xxxxxxxxxxx> wrote: > In many userspace applications, and especially in VM based > applications like Android uses heavily, there are multiple different > allocators in use. At a minimum there is libc malloc and the stack, > and in many cases there are libc malloc, the stack, direct syscalls to > mmap anonymous memory, and multiple VM heaps (one for small objects, > one for big objects, etc.). Each of these layers usually has its own > tools to inspect its usage; malloc by compiling a debug version, the > VM through heap inspection tools, and for direct syscalls there is > usually no way to track them. > > On Android we heavily use a set of tools that use an extended version > of the logic covered in Documentation/vm/pagemap.txt to walk all pages > mapped in userspace and slice their usage by process, shared (COW) vs. > unique mappings, backing, etc. This can account for real physical > memory usage even in cases like fork without exec (which Android uses > heavily to share as many private COW pages as possible between > processes), Kernel SamePage Merging, and clean zero pages. It > produces a measurement of the pages that only exist in that process > (USS, for unique), and a measurement of the physical memory usage of > that process with the cost of shared pages being evenly split between > processes that share them (PSS). > > If all anonymous memory is indistinguishable then figuring out the > real physical memory usage (PSS) of each heap requires either a pagemap > walking tool that can understand the heap debugging of every layer, or > for every layer's heap debugging tools to implement the pagemap > walking logic, in which case it is hard to get a consistent view of > memory across the whole system. > > This patch adds a field to /proc/pid/maps and /proc/pid/smaps to > show a userspace-provided name for anonymous vmas. The names of > named anonymous vmas are shown in /proc/pid/maps and /proc/pid/smaps > as [anon:<name>]. I'm pretty wobbly about this. - Fishing around in another process's user memory for /proc strings is unusual and problems might crop up if we missed something. - Adding thing to the userspace interface is a big deal, because we should continue to support them evermore. This becomes more of a concern when the implementation and interface is so unusual. - I'm not aware of anyone else expressing interest in or a need for this extension, and Android are well able to carry their own kernel patches. - otoh, it's undesirable that external groups carry their own patches, and we should try to get these things integrated to better serve our users. So, wobble wobble. Does anyone else have an opinion? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>