ARMMemoryFootprint

Differences between revisions 3 and 4
⇤ ← Revision 3 as of 2010-05-07 17:15:45 →
Size: 5342
Editor: dave-martin-arm
Comment:
← Revision 4 as of 2010-05-13 08:09:13 → ⇥
Size: 7058
Editor: asac
Comment:
Deletions are marked like this. Additions are marked like this.
Line 120: Line 120:
Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.
 * work on low hanging fruits now and improve measurement techniques and tools for
   future integration
 * minimal filesystem with just a shell would allow to run something on low mem
   platforms. constraints:
   * low amount of memory
   * smaller caches
 * library duplication
  * openssl / gnutls
 * -Os needs to be measured to understand the runtime performance impact
   (but we build for Thumb2, so we reduce space and sometimes gain speed)
 * finding dead library tool code: callgrind/valgrind
  * massif (from valgrind) also potentially useful for heap profiling
 * Link Time Dead Code and Data Elimination Using GNU Toolchain
  * http://elinux.org/images/2/2d/ELC2010-gc-sections_Denys_Vlasenko.pdf
   (not available yet for ARMv7 but being worked on)
 * Reprofiling the boot process for ARM could be useful
  * upstart currently optimized mainly based on x86 world ... arm might benefit from benchmarking
    and tuning this arch specific.
 * Default VM tuning parameters may benefit from profiling for ARM - use different defaults for ARM versus x86, or per platform?
 * Build kernel for thumb2?
  * Likely to run into alignment bugs, so sooner rather than later
 * Coverage measurement?
  * Haphazard in Ubuntu
 * how much of libc is used by the standard use case
   * mklibs on installed/embedded systems
   * the libc.a could be kept on disk and after installing packages, mklibs could be run to
     produce a lib with exactly what is currently used
   * doubtful whether there would be a consierable win if you do this for a real install, e.g.
     just the installer atm already pulls in 70% -> could be investigated in an experiment
 * Ubuntu/Debian has a library reduction tool - mklibs
 * uclibc? (Nicolas says it can run firefox) - internationalisation limitations
 * xmap(-console) may be a useful memory measurement tool

Summary

Discuss possibilities for reducing memory footprint to improve performance, and identify useful optimisations and investigations which should be carried out.

Points for discussion

Strategy

  • What key memory hogs can we identify immediately?
    • Xorg?
    • what else?
  • Can we reduce the number of libraries duplicating each other's functionality?
  • Can we reduce the number of interpreters required by the base system and the boot process?
  • Are there tools for finding and removing dead code from libraries?
  • Converting from hard dynamic linking to a plugin model for libraries providing rarely-used functionaliy, to avoid loading (and maybe avoid installing) libraries which may commonly be unused
  • Wider use of -Os ?
  • Improve page cache performace tradeoff by using different /proc/sys/vm defaults for mobile devices?

  • Power benchmarking (may overlap with https://blueprints.launchpad.net/ubuntu-arm/+spec/arm-m-kernel-power-management-consolidation)

Memory profiling / benchmarking

  • Mechianisms:
    • BSD process accounting
    • Does bootchart already support it / can it easily be extended?
  • How to define "memory usage"
    • VM allocation? (easliy measured, can be misleading - some processes allocation much more VM than is actually used)
    • Resident Set Size (easily measured via ps or proc, can be misleading and hard to interpret)
    • A custom approach which examines /proc/*/maps to try to take shared memory into account (VM/RSS don't cope with this)
    • Extend BSD process accounting to dump additional info? (currently only "average mem" is reported, seems to = the average VM allocation over the process lifetime)
  • Memory use profiling and measurement tools

Cross-References

Release Note

Run-time memory optimisations help to get the best performance and battery life from lightweight and mobile devices.

Rationale

Mobile devices have sensitivity to RAM usage which differs from heavyweight laptops / desktops due to:

  • generally smaller cache sizes (32+32K L1 + 256-512K L2 appears typical)
  • complex memory maps giving rise to a large working set of pages, and the interaction of this with generally small TLBs
  • demand paging may thrash caches and TLBs, slowing boot and application launch
  • power overheads of reading external RAM into cache impact on battery life
  • some devices have restricted RAM in which a standard Ubuntu stack won't fit easily
    • OMAP3 with 256MB for example

Optimising memory footprint has potential to being speed improvements (particular boot, login and app launch times) and improved power efficiency + battery life.

User stories

Assumptions

Design

<!-- You can have subsections that better describe specific parts of the issue. --> TBA

Implementation

<!-- This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like: --> TBA

UI Changes

TBA

  • Memory concerns could influence the choice of graphics stack.

Code Changes

<!-- Code changes should include an overview of what needs to change, and in some cases even the specific details. --> TBA

Migration

<!-- Include:

  • data migration, if any
  • redirects from old URLs to new ones, if any

  • how users will be pointed to the new way of doing things, if necessary. -->

TBA

Probably no end user impact, but there may be software migration issues.

Test/Demo Plan

Before/after demonstration a full stack on OMAP (256MB)?

It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.

This need not be added or completed until the specification is nearing beta.

Unresolved issues

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

BoF agenda and discussion

  • work on low hanging fruits now and improve measurement techniques and tools for
    • future integration
  • minimal filesystem with just a shell would allow to run something on low mem
    • platforms. constraints:
    • low amount of memory
    • smaller caches
  • library duplication
    • openssl / gnutls
  • -Os needs to be measured to understand the runtime performance impact
    • (but we build for Thumb2, so we reduce space and sometimes gain speed)
  • finding dead library tool code: callgrind/valgrind
    • massif (from valgrind) also potentially useful for heap profiling
  • Link Time Dead Code and Data Elimination Using GNU Toolchain
  • Reprofiling the boot process for ARM could be useful
    • upstart currently optimized mainly based on x86 world ... arm might benefit from benchmarking
      • and tuning this arch specific.
  • Default VM tuning parameters may benefit from profiling for ARM - use different defaults for ARM versus x86, or per platform?
  • Build kernel for thumb2?
    • Likely to run into alignment bugs, so sooner rather than later
  • Coverage measurement?
    • Haphazard in Ubuntu
  • how much of libc is used by the standard use case
    • mklibs on installed/embedded systems
    • the libc.a could be kept on disk and after installing packages, mklibs could be run to
      • produce a lib with exactly what is currently used
    • doubtful whether there would be a consierable win if you do this for a real install, e.g.

      • just the installer atm already pulls in 70% -> could be investigated in an experiment

  • Ubuntu/Debian has a library reduction tool - mklibs
  • uclibc? (Nicolas says it can run firefox) - internationalisation limitations
  • xmap(-console) may be a useful memory measurement tool

CategorySpec

Specs/M/ARMMemoryFootprint (last edited 2012-10-10 15:54:34 by mfisch)