Re: [PATCH 2/2] mm: add a field to store names for private anonymous memory

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jul 11, 2013 at 10:43 PM, Pekka Enberg <penberg@xxxxxxxxxx> wrote:
> On 07/12/2013 05:34 AM, Colin Cross wrote:
>>
>> Userspace processes often have multiple allocators that each do
>> anonymous mmaps to get memory.  When examining memory usage of
>> individual processes or systems as a whole, it is useful to be
>> able to break down the various heaps that were allocated by
>> each layer and examine their size, RSS, and physical memory
>> usage.
>>
>> This patch adds a user pointer to the shared union in
>> vm_area_struct that points to a null terminated string inside
>> the user process containing a name for the vma.  vmas that
>> point to the same address will be merged, but vmas that
>> point to equivalent strings at different addresses will
>> not be merged.
>>
>> Userspace can set the name for a region of memory by calling
>> prctl(PR_SET_VMA, PR_SET_VMA_ANON_NAME, start, len, (unsigned long)name);
>> Setting the name to NULL clears it.
>>
>> The names of named anonymous vmas are shown in /proc/pid/maps
>> as [anon:<name>] and in /proc/pid/smaps in a new "Name" field
>> that is only present for named vmas.  If the userspace pointer
>> is no longer valid all or part of the name will be replaced
>> with "<fault>".
>>
>> The idea to store a userspace pointer to reduce the complexity
>> within mm (at the expense of the complexity of reading
>> /proc/pid/mem) came from Dave Hansen.  This results in no
>> runtime overhead in the mm subsystem other than comparing
>> the anon_name pointers when considering vma merging.  The pointer
>> is stored in a union with fieds that are only used on file-backed
>> mappings, so it does not increase memory usage.
>>
>> Signed-off-by: Colin Cross <ccross@xxxxxxxxxxx>
>
>
> So how does this perform if I do prctl(PR_SET_VMA_ANON_NAME)
> for thousands of relatively small (max 1 KB) JIT generated
> functions? Will we run into MM problems because the VMAs are
> not mergeable?

This operates on vmas, so it can only handle naming page aligned
regions.  It would work fine to identify the regions that contain JIT
code, but not to identify individual functions.

--
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>




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]