Summary

Release Note

This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented. (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.)

It is mandatory.

Rationale

User stories

Assumptions

Design

You can have subsections that better describe specific parts of the issue.

Implementation

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

UI Changes

Should cover changes required to the UI, or specific UI that is required to implement this

Code Changes

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

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.

Test/Demo Plan

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

Goal is using modern CPU features in Linaro kernels

  • NEON
    • debug support (e.g. making sure the registers are saved in core files)
    • string routines
      • Need to measure how much it gains to switch to these
      • Cortex-A8 versus A9 makes a difference, measure both
      • Should send some UDP workload, netperf, TCP checksums etc. would be good workloads
      • Could use for some crypto implementations as well
  • We don't use Altivec
  • Build the kernel as Thumb 2
  • HIGHMEM
    • Need to measure whether it has an impact when it's enabled but not used
      • Benchmark needs to use a lot of paging
    • SD driver had performance degraded with HIGHMEM turned on
    • Need to test on all boards because it does break some boards right now
    • Need to ensure there is no performance degradation in kernel drivers as a result of highmem
  • SMP on UP
    • Russell working on a set of patches providing that
    • Architecture independent
    • Need to be ported to Thumb 2
  • SMP
    • Hotplug is being worked on in the power management working group
    • SMP and PREEMPT often exposes funny bugs, but PREEMPT is often turned on
    • Private peripheral interrupts will be an issue with SMP
      • Could remove current hack with local time and do it properly
    • Will posted some patches to fix kgdb SMP support
      • Mostly generic code, using the wrong atomic operations
  • Thumb 2
    • Kprobes has to be reimplemented entirely for Thumb 2
    • Ftrace without dynamic ftrace would be crazy, so we need to make sure ftrace and dynamic ftrace work on T2
    • oprofile or perf events do userspace backtraces
      • Need wider discussion with the toolchain working group
      • Need to fix the userspace side to use libunwind (Toolchain WG)
      • Need to fix the kernel side to do proper backtraces in any case
      • Investigate how userspace can pass unwind tables to the kernel to do this properly

* Multiple libc implementations - check memcpy etc in each

  • glibc

Some hardware (Marvell perhaps) may be too slow even to saturate network.

  • - Marvell and others tend to use a basic design they reuse for different
    • products and don't care that much about performance.
  • EXPERIMENTAL
    • U-Boot built as Thumb 2 as a nice to have
  • Cache maintenance operations on ARMv7 are expensive: cache geometry is probed every time some cache maintenance is required; need to fix this for better performance; should improve DMA and I/O substantially

Actions

  • Confirm with Toolchain WG what's missing and implement support for NEON registers in core files
  • Loïc to check if Toolchain WG can provide suitable memcpy routines and test cases for the kernel -- it's different in that the context might be more limited in the kernel
  • Integrate optimized memcpy routines and measure performance
  • Help finish and then integrate SMP on UP patchset, test on all supported platforms
  • Fix SMP on UP for Thumb 2 and test
  • Find a good benchmark for highmem and then benchmark a kernel with and without highmem, when not using high memory
  • Enable highmem on all architectures, test that they build and boot
  • Benchmark drivers like SD, USB etc. with highmem turned on
  • Merge hotplug support from power mgmt wg
  • Turn PREEMPT on in test farm
  • Investigate PPI (Private Peripheral Interrupt) on SMP -- might not work with some devices, XXX which devices?
  • Build and test all kernels for Thumb 2
  • Implement Kprobes for Thumb 2
  • Fix dynamic ftrace for Thumb 2
  • (experimental) Build u-boot in Thumb 2 mode
  • Investigate and fix kgdb on SMP
  • Implement caching / factor out cache geometry at runtime


CategorySpec

Specs/KernelStandardArchitecture (last modified 2011-01-13 18:22:11)