| Age | Commit message (Collapse) | Author |
|---|
|
This reverts commit 4bf06a51869f49d7ee3fb0163a2517ec5e33ba1f.
Bug: 17360804
Bug: 17332389
Change-Id: I7e4d55215f391f5b3f71388943e9d95e5eff6f81
|
|
see comment above pagemap_read() from the kernel
Bug: 17332389
Change-Id: Iaec9a2c8d2783f5c1e7ba06d9c7156305abe0453
Signed-off-by: Daniel Rosenberg <drosen@google.com>
|
|
Use uint64_t and lseek64 to handle 64-bit virtual addresses
when libpagemap is compiled as a 32-bit library.
Change-Id: Ie4b6c7ef05aac604011f3ee28b059d9dfcd63edb
|
|
libpagemap was storing a virtual pfn in an int, which works on arm64
with 39 bits of virtual address space but fails on x86_64. Use an
unsigned long instead.
Fixes errors when running procrank on x86_64:
warning: could not read usage for 1
Change-Id: I171c8ee49faa51accf3c1bb69059d549aee04979
|
|
|
|
/proc/pid/maps may report a zero-length memory region for a 4kB
PROT_GROWSDOWN region because it subtracts 4kB for the guard page.
Return 0 instead of -1 when this occurs, and set range_out to NULL
and len to 0. All existing callers of pm_process_pagemap_range
will not dereference range_out if len is 0.
Bug: 14683277
Change-Id: If405651ad034dda780b93fab2dc616e177a0b917
|
|
Enable this header to be cleanly included in C++ code.
Change-Id: Ie4ae60629661237ce07b49b17802f01bf95552d8
|
|
procrank/librank not impacted because they end quickly. But other
programs that use libpagemap and last for long time can easily see this
memory leak.
Change-Id: I8c9e9444555bef9145c9d89850987a29f15a9b3b
Signed-off-by: Carton He <carton.he@marvell.com>
|
|
Add pm_process_usage flags to get memory usage by a process, only
counting pages with specified flags set.
Change-Id: I900b673ddbb5ae92312773a8670dd59769617268
|
|
Change-Id: I6b030d9d0356d63b3ddb853de304407bc70b38c4
|
|
Add a new memusage field for swapped pages.
Change-Id: I857143a5fdd294315dd89e834b1217a219f10479
|
|
Add pm_map_usage_flags, which is the same as pm_map_usage but only
counts pages with the specified flags set. This can be used to
only count "swapbacked" pages, which are pages that cannot be
flushed back to disk without using swap.
Change-Id: I6367555d9385502c797935849bb4221a8354e251
|
|
Change-Id: If4a4a2bbe9b1a68c5dce1151cf8b7c60cae1a3fa
|
|
Change-Id: Ibd0b26e4f5245592152d2c8ef00e7da1ad5f3fdf
|
|
pm_map_usage was not incrementing vss for pages that were in the
process's map but not occupying a physical page. Move the
vss increment above the check for present mappings.
Change-Id: I2706e6fbcbfe7d70f10950333a486d690bc84d6c
|
|
Mappings that are not from a file do not have a name. The sscanf
will read all of the fields up to the name, and then leave name
untouched. This causes the previous name to be reused. Reset
name to an empty string before each call to sscanf.
Change-Id: Ib146732983eb074d0d4773be094efa0b672f5ed2
|
|
Fixed these problems:
1. Page swapped bit was not extracted correctly.
2. Pages were ignored when page present bit is not set.
3. Bit operations were not correct.
4. There was a compiler warning about unsigned/signed comparision.
5. Line limit was too short for the map file. This was causing procrank
to generate a warning and remove the related process from results.
Change-Id: Ifed3913a49b15f59010cfa842090a13228074df9
|
|
Instead of handling maps with the name "[vectors]" specially,
silently ignore EOF when reading from /proc/<pid>/pagemap, which
occurs any time a a mapping is outside of the userspace range.
Change-Id: I674ade1eab6fd7732c6d9e120d0750cca5415b25
|
|
In kernel 2.6.37, the vector page was added to /proc/<pid>/maps,
but because it is located above TASK_SIZE (usually 0xbf000000),
it is considered to be in the kernel's address space, not the
process', so it doesn't show up in /proc/<pid>/pagemap.
When the vector page is detected, using the name "[vectors]",
remove it from the map.
Change-Id: I5f0758bbe5d2b927056fa9fee684fea63dd0fa4b
|
|
Change-Id: I1b3e13f0e16b51604852437b32b1d8309471abc8
|
|
|
|
|
|
|
