[prev in list] [next in list] [prev in thread] [next in thread] 

List:       uclinux-dev
Subject:    [uClinux-dev] 2.6.38 in Freescale Feb 2012 BSP
From:       "Bair, Richard" <richard.bair () thermofisher ! com>
Date:       2013-09-27 15:04:30
Message-ID: 61D47DD7179B074AB587E84DC0461D7D06EF9FBC8B () USPHO-MXVS01 ! amer ! thermo ! com
[Download RAW message or body]

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
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev


[prev in list] [next in list] [prev in thread] [next in thread]