Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Given the following output, can someone tell me:
1) Hex Decimal
080b0fff = 134942719
08048000 = 134512640
Diff = 430079
Why does pmap indicate the size as 420k?
2) What's the purpose of the Offset column when the whole address range is shown?
3) The "rwxpc" column indicates that this segment is readable, executable, private, and the + sign indicates that COW is required.
If there has been 3 forks (ie 1 parent and 3 child processes), and only of these three child processes has attempted to write to the segment, is this enough to cause this + sign to change to a - sign? Or all 3 child processes needs to have attempted to write to the segment, and all 3 has a COW, before the - sign will appear?
4) What does the I/W/A column indicate?
Code:
$ pmap -a
Start End Size Offset rwxpc RWX I/W/A ...
08048000-080b0fff 420k 00000000 r-xp+ (rwx) 1/0/0 ...
420k is really 420KiB, meaning 420 x 1024 bytes (ie 430080 bytes). We've been happily misusing SI prefixes for some time now
Quote:
What's the purpose of the Offset column when the whole address range is shown?
It's just the offset into the paging object.
Quote:
If there has been 3 forks (ie 1 parent and 3 child processes), and only one of these three child processes has attempted to write to the segment, is this enough to cause this + sign to change to a - sign?
If the region is shared by multiple processes, then the copied flag would have to remain 'uncopied' while there was more than one process still capable of writing to it (ie, the shared region cannot change to '-' until each process has its own copy).
Quote:
What does the I/W/A column indicate?
The 'I' is the inheritance type of the region (ie, whether child processes share, copy or do not have the region); the 'W' is the wired count of the region (ie, whether the region is wired in and cannot be paged, as is typical of kernel memory); the 'A' is the advice parameter (ie, hints regarding the page priority of the region).
Last edited by neonsignal; 05-08-2011 at 06:24 AM.
neonsignal, thanks for the explanations. Regarding the following, can you give me some examples of what is a "wired count"? I'm not following what you meant by "whether the region is wired in". As for the number "1" under the "I" column, I guess this is because the memory is shown as a COW type with the "+" sign under the "rwxpc" column?
Quote:
The 'I' is the inheritance type of the region (ie, whether child processes share, copy or do not have the region); the 'W' is the wired count of the region (ie, whether the region is wired in and cannot be paged, as is typical of kernel memory); the 'A' is the advice parameter (ie, hints regarding the page priority of the region).
BTW, I've noticed differences between the pmap and jmap output. Can you tell me how I should account for the differences?
can you give me some examples of what is a "wired count"?
These are pages that cannot be swapped out, typically memory that is being used by the kernel - stacks, memory pools, page tables, and the like).
Quote:
As for the number "1" under the "I" column, I guess this is because the memory is shown as a COW type with the "+" sign under the "rwxpc" column?
No, it means that this page is of type VM_INHERIT_COPY, meaning that child processes will get a copy of the page (which is the default). The COW is showing how any copies are to be handled (functionally).
Quote:
BTW, I've noticed differences between the pmap and jmap output. Can you tell me how I should account for the differences?
I haven't used jmap, I'll leave that question for someone else! You might want to give an example.
No, it means that this page is of type VM_INHERIT_COPY, meaning that child processes will get a copy of the page (which is the default). The COW is showing how any copies are to be handled (functionally).
Thanks. Would I be correct if I say, however, that if there is no COW, as indicated with the "+" sign, then there won't be a "1" under the "I" column also? Basically the way I get what you are saying is that the "1" under the "I" column means the child will get a copy, and the "+" means the child will get the copy when it attempts to write to that area. Right?
Basically the way I get what you are saying is that the "1" under the "I" column means the child will get a copy, and the "+" means the child will get the copy when it attempts to write to that area.
Yes. I was just being pedantic in pointing out that in theory the child could still get a copy even if the system didn't have a copy-on-write mechanism (instead just a straightforward copy). And you could have a copy-on-write page that is memory shared between unrelated processes, even if it wasn't a page that was inheritable by child processes. In other words, that the two concepts are independent. But in practice, yes, a page that is going to be inherited by the child will be copied when the child (or parent) writes to it.
Last edited by neonsignal; 05-23-2011 at 06:11 PM.
For the jmap vs pmap output example, here's what I see (truncated a lot of other stuff).
Essentially the key points I notice are:
1) jmap lists the code section and pmap lists both code and data sections.
2) Size in jmap is different than size in pmap.
For example:
46k vs 40k for java
1225k vs 104k for ld-2.4.so
1261k vs 104k for liba.so
47343k vs 31652k for liba.so
3) pmap lists things like [heap], [anon]. What are these?
Can I ask, based on looking at pmap, how can I tell what is the stack and heap boundary addresses?
jmap lists the code section and pmap lists both code and data sections. Size in jmap is different than size in pmap.
It looks more like jmap is including code and the other segments into a single total. If you add the pmap segments, you get roughly the same totals.
For example,
Code:
for java -> 46k vs 40k+4k
for ld-2.4.so -> 125k vs 104k+8k+4k+4k+4k
for liba.so -> 1261k vs 104k+20k+...+972k+52k
and so on
Quote:
pmap lists things like [heap], [anon]. What are these?
These are just different segments used by the executable. The code segment is obvious (because it is not writable). But there can also be initialized data segments, uninitialized data segments, dynamically allocated data space (heap), and stack space, etc (the exact set of segments used can vary).
Quote:
Can I ask, based on looking at pmap, how can I tell what is the stack and heap boundary addresses?
Once the heap and stack segments are located, can't you just add the size to the start address to get the end address? Is that what you mean?
Thanks. Didn't realize that jmap is adding the code and data segment. As for
Quote:
Once the heap and stack segments are located, can't you just add the size to the start address to get the end address? Is that what you mean?
I suppose so. However, I'm not sure if the stack or heap may be broken up in a non-contiguous memory space. If so, I guess the lowest address for the stack(s) is the top of the stack, and the highest address for the heap(s) is the top of the heap. However, what would the heap be indicated as? Is it [anon]? Anyway to see look at what's on the stack?
I'm not sure if the stack or heap may be broken up in a non-contiguous memory space.
The mapping is only a virtual address space, not a real one. The stack is necessarily contiguous in this virtual address space (in theory, one could implement a non-contiguous stack, but on current systems it would be seen as an unnecessary complication). The heap doesn't have to be contiguous, but typically implementations are (which is why it is allocated at the end of all the low address segments, so that it can dynamically grow).
The pmap can't be relied upon to identify segment types (the contents will vary depending on how the language/code works). Often the heap will be the largest writable segment at the end of the low address segments, and the stack will be the last of the high address segments.
Quote:
If so, I guess the lowest address for the stack(s) is the top of the stack
Yes, the stack is growing from the end address towards the base address.
Quote:
and the highest address for the heap(s) is the top of the heap.
Yes, although a heap can be grown at run time, so that isn't a hard limit.
Quote:
However, what would the heap be indicated as?
Depends on how smart the pmap implementation is. Your example above had the heap identified, but on some systems it may be just another 'anon' segment.
To view the contents of these address spaces, it would be usual to employ a debugger (eg use gdb to dump memory contents). In a Java context, it might be more useful to run a Java debugger, though that might not have quite the same low level functionality?
Last edited by neonsignal; 05-26-2011 at 06:47 PM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.