Difference between revisions of "Kernel dynamic memory analysis"
(Created page with "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 ==...") |
|||
Line 30: | Line 30: | ||
== Recommendations for reductions == | == 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) | ||
+ | |||
??? | ??? |
Revision as of 11:47, 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...]
Contents
Instrumentation
- slab_accounting patches
- use __builtin_return_address(0) to record the address of the caller
- this 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
- use __builtin_return_address(0) to record the address of the caller
- kmem events
- does not start until ftrace system is initialized, after some allocations are already performed
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
- grouping allocations (assigning to different subsystems, processes, or functional areas)
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)
???