Bair, Richard
2013-09-27 15:04:30 UTC
Still struggling with 2.6.38 kernel and memory allocation. We've been RTFMing but still aren't able to run on 2.6.38. Any insight much appreciated.
BACKGROUND:
===========
- Application is unchanged and runs on 2.6.26 and not on 2.6.38. Both versions are based on Freescale BSP releases.
- Application only has 32MB of RAM total...same for both working and failing case.
- Application will "spawn" 3x additional threads.
- Application is 4.7MB application...it appears to allocate 8Mb then an additional 8MB for each thread. I believe this occurs via vfork().
THOUGHTS:
=========
- It is my understanding that 2^n allocation has been present since 2.6 introduction so I think this is the same from version 26 to 38.
Q1: Does the kernel always allocate memory via mmap()?
Q2: Is mmap() used for kernel allocation and user-land allocation?
Q3: Is there a good summary of exactly what transpires in terms of memory allocation as the kernel runs a user-land program?
- If mmap() is the primary allocator, I think there may be a "trimming capability" difference from 26 to 38 based on Len Sorensen's input for memory allocations by mmap() as follows:
(1) Keep the excess as dead space. The dead space then remains unused for the
lifetime of the mapping. Mappings of shared objects such as libc, ld.so
or busybox's text segment may retain their dead space forever.
(2) Return the excess to the allocator. This means that the dead space is
limited to less than a page per mapping, but it means that for a transient
process, there's more chance of fragmentation as the excess space may be
reused fairly quickly.
Q4: Has anyone used option 2 and if so exactly how do you set the variable and when? For the when part, do you do this post the kernel bring up?
Q5: It sounds like a common method is to not "trim" during boot and then turn this on for large memory allocations...true? Recommended?
Q6: Can anyone confirm if 26 was configured to always trim memory after allocation and 38 is not?
- Tools for better memory utilization debug:
Q7: What tools can we use to better understand the memory footprint of the application and threads? We're using Top but need significantly more detail.
Q8: Is there a proc location that details memory allocation per program?
In summary, any recommendations on how to debug memory allocation would be most helpful. At this time our Freescale support has been unhelpful in resolving this issue.
Thanks!
-Rich
BACKGROUND:
===========
- Application is unchanged and runs on 2.6.26 and not on 2.6.38. Both versions are based on Freescale BSP releases.
- Application only has 32MB of RAM total...same for both working and failing case.
- Application will "spawn" 3x additional threads.
- Application is 4.7MB application...it appears to allocate 8Mb then an additional 8MB for each thread. I believe this occurs via vfork().
THOUGHTS:
=========
- It is my understanding that 2^n allocation has been present since 2.6 introduction so I think this is the same from version 26 to 38.
Q1: Does the kernel always allocate memory via mmap()?
Q2: Is mmap() used for kernel allocation and user-land allocation?
Q3: Is there a good summary of exactly what transpires in terms of memory allocation as the kernel runs a user-land program?
- If mmap() is the primary allocator, I think there may be a "trimming capability" difference from 26 to 38 based on Len Sorensen's input for memory allocations by mmap() as follows:
(1) Keep the excess as dead space. The dead space then remains unused for the
lifetime of the mapping. Mappings of shared objects such as libc, ld.so
or busybox's text segment may retain their dead space forever.
(2) Return the excess to the allocator. This means that the dead space is
limited to less than a page per mapping, but it means that for a transient
process, there's more chance of fragmentation as the excess space may be
reused fairly quickly.
Q4: Has anyone used option 2 and if so exactly how do you set the variable and when? For the when part, do you do this post the kernel bring up?
Q5: It sounds like a common method is to not "trim" during boot and then turn this on for large memory allocations...true? Recommended?
Q6: Can anyone confirm if 26 was configured to always trim memory after allocation and 38 is not?
- Tools for better memory utilization debug:
Q7: What tools can we use to better understand the memory footprint of the application and threads? We're using Top but need significantly more detail.
Q8: Is there a proc location that details memory allocation per program?
In summary, any recommendations on how to debug memory allocation would be most helpful. At this time our Freescale support has been unhelpful in resolving this issue.
Thanks!
-Rich