Difference between revisions of "Kernel dynamic memory analysis"

From eLinux.org
Jump to: navigation, search
(Instrumentation)
Line 5: Line 5:
 
== Instrumentation ==
 
== Instrumentation ==
 
* slab_accounting patches
 
* slab_accounting patches
** use __builtin_return_address(0) to record the address of the caller
+
** uses __builtin_return_address(0) to record the address of the caller
*** this same mechanism used by kmem events
+
*** this is same mechanism used by kmem events
 
*** if gcc decides to inline automatically, you get the wrong call site
 
*** if gcc decides to inline automatically, you get the wrong call site
 
**** can disable automatic inlinining with a compiler flag
 
**** can disable automatic inlinining with a compiler flag
Line 13: Line 13:
 
* kmem events
 
* kmem events
 
** does not start until ftrace system is initialized, after some allocations are already performed
 
** does not start until ftrace system is initialized, after some allocations are already performed
 +
** supported in mainline - no need to add our own instrumentation
 +
 +
Focus of work right now is to see if kmem events can be used to find early allocations.
 +
Also, to see if early allocations account for significant memory usage.  If not, it may
 +
not be that important to capture them.  [Is another possibility some way to use a printk approach
 +
for very early allocations, and somehow coalesce the data into the final report?]
  
 
== Reporting ==
 
== Reporting ==

Revision as of 11:52, 15 August 2012

This page has notes and results from the project Kernel dynamic memory allocation tracking and reduction

[This page is fairly random at the moment...]

Instrumentation

  • slab_accounting patches
    • uses __builtin_return_address(0) to record the address of the caller
      • this is same mechanism used by kmem events
      • if gcc decides to inline automatically, you get the wrong call site
        • can disable automatic inlinining with a compiler flag
    • starts from very first allocation
  • kmem events
    • does not start until ftrace system is initialized, after some allocations are already performed
    • supported in mainline - no need to add our own instrumentation

Focus of work right now is to see if kmem events can be used to find early allocations. Also, to see if early allocations account for significant memory usage. If not, it may not be that important to capture them. [Is another possibility some way to use a printk approach for very early allocations, and somehow coalesce the data into the final report?]

Reporting

  • extracting data to host
    • tool for extraction (perf?)
  • post-processing the data
    • grouping allocations (assigning to different subsystems, processes, or functional areas)
      • idea to post-process kmem events and correlate with */built-in.o
    • reporting on wasted bytes
    • reporting on memory fragmentation

Visualization

    • possible use of treemap to visualize the data

Mainline status

  • is anything added to mainline via this project?

Recommendations for reductions

Results so far (in random order)

  • There's a lot of fragmentation using the SLAB allocator. [how much?]
  • SLxB accounting is a dead-end (it won't be accepted into mainline)

???