Parent


LEG-SC
<< <  2020 / 5 >  >>
Mon Tue Wed Thu Fri Sat Sun
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31

Attendees

Hosted by Facebook in building 17, Menlo Park:

  • Anmar Oueja (Linaro)
  • Ilias Biris (Linaro)
  • Andrea Gallo (Linaro)
  • Leo Duran (AMD)
  • Kumar Sankaran (Applied Micro)
  • Jeff Underhill (ARM)
  • Larry Wikelius (Calxeda)
  • Rob Herring (Calxeda)
  • Kiko (Canonical)
  • Prasun Kapoor (Cavium)
  • Ali Adl-Tabatabai (Facebook)
  • Tim Wesselman (HP)
  • Assaf Hoffman (Marvell)
  • Jon Masters (Red Hat)
  • Elsie Wahlig (Samsung)
  • Bill Mills (TI)

Minutes

Download the complete slide set presented at the meeting: LEG Management Update 15-Jan-2013.pdf

Linaro Connect

Next Connect Schedule:

  • March 4th - 8th Hong Kong
  • July 8th - 12th Dublin
  • Oct 28th - Nov 1st San Jose

Connect objectives:

  • Information sharing from LEG teams with other Linaro, external teams
  • Solicit input from other
  • Breakout rooms to work F2F with other assignees from day to day work
  • Bring the virtual teams together in person
  • Team building

Sessions

  • UEFI / Tue 9-10
    • Updates on the maintainership rules, Linaro tree, SCT and test integration in LAVA, collaboration with ARM and the Tianocore community.
  • ACPI / Tue 10-11
    • Updates on ACPICA porting on ARM and initial trials with ACPI tables.
    • Demo session on adding ACPI support for a power button driver in comparison with device tree tables.
  • Verticals: web server and caching technologies / Tue 11-12
    • Enable the web server vertical application use case, evaluate the performance, identify potential bottlenecks and look into caching technologies and reverse proxies.
  • Verticals: HipHopVM and Hadoop Distributed File System / Tue 12-13
    • Updates on HipHopVM porting onto the v8 Foundation model, interpreter and bytecode jitting.
    • Updates on Hadoop Distributed Filesystem performance.
    • Plans for distributed DB and key value sets.
  • KVM / Wed 10-11
    • Common session with the Kernel WG and LNG about KVM status and plans for A15 and v8 architectures, IO virtualization and OpenStack as a test case.

  • LAVA and hyperscale multi-node server testing / Wed 11-12
    • Update and plans to support testing of hyperscale multi-node servers with LAVA, discussions around distributed storage or cloud computing test cases, etc.
  • Verticals: Distributed computing / Thu 10-11
    • Plans for distributed computing, OpenMPI, Hadoop, OpenStack

  • Assembly Dependencies / Fri 9-10
    • Update on the scanning of Ubuntu and Fedora packages for assembly dependencies and plans for optimizations.

Questions:

  • Ali would like to be able to add tests to LAVA for v8 testing and validation
    • Owen to join the ongoing learning curve on LAVA with Fu Wei
  • Facebook would also be interested in talking to engineers with experience generating ARM v8 instructions; we will build a JIT compiler as part of our HHVM port to ARM v8
    • Organize a BOF session on JIT and code generators

Membership update

LEG Management Update 15-Jan-2013(6).png

LEG Management Update 15-Jan-2013(7).png LEG Management Update 15-Jan-2013(8).png LEG Management Update 15-Jan-2013(9).png LEG Management Update 15-Jan-2013(10).png

Important note: the sponsors for each of the Verticals to work with the Assignees to assess the Cards and the work required to ensure that we can deliver on the proposed roadmap

Roadmap discussion

LEG Management Update 15-Jan-2013(11).png

  • Current milestones reflect introduction dates
  • 32/64 flags color swim lanes to explain the code base targeted (v7/v8)
  • The icons show the current snapshot of the milestones and evolve in time as the status progresses from concept to planning and then development/delivery for each one
    • add the snapshot date on each roadmap update

  • KVM
    • Kiko: organize a get together on KVM asap incl ARM? e/o January?
  • UEFI
    • UEFI and GRUB on UEFI: when on v8? cards are available, to be finalized and then added to the roadmap
    • PXE
      • Jeff: any network std layer?
      • Bill: Reece working on VE model and also BeableBone which has std network

      • Rob: PXE is a DHCP extension, what does PXE boot mean here? Reece detailing the card
      • Bill/Jeff: Kiko and John to review the card as there are many options in PXE

Further investigation

LEG Management Update 15-Jan-2013(12).png

  • UEFI
    • PCIe - Tim expressed the need for boot over PCIe, stating the example that a boot device may be in the same server enclosure, but not directly attached to the ARM SoC. As such, booting over PCIe would be required.
    • Option ROM - Jon explained that LEG would allow option ROM support, but would not try to enable complex modes such as x86 translation or emulation
      • PCI-e option ROM discussion - don’t expect large numbers of devices in the early stages. Handle on case by case basis with native PCI-e option ROM or UEFI EBC for foreseeable future
  • (ACPI) Runtime service
    • Runtime services, RAS, etc
    • Power management
    • Elsie shared that there is a hardware reduced ACPI feature in v5 spec, this may work for us
    • Jon commented that there is no need for us to duplicate x86 ACPI on ARM. We need to select the optimum set for enablement.
      • CPUFreq driver for each SoC today in kernel - advantage of this approach is it’s open source and can be updated (same if it’s in a custom kernel)
      • ACPI structures / methods in firmware are not as accessible for modification
      • Provide a minimal set of powers that any ARM server would be expected to implement, with the opportunity for vendor enhancements for additional states
    • Action - Anmar requested that we solicit power management guidance from HP, FaceBook, other OEMs on the various power states that will be desired.

      • Create a baseline of states which are expected to work - expand on those as needed per platform
    • Define *minimum* server power management requirements and boundaries for kernel vs ACPI responsibility. E.g.:
      • CPU: On (C0), Off (C1 - Halt)
      • G-states: G0, G2 (WOL state) & G3 (Mechanical off)

      • S-states: Not needed as they are relevant in G1 (sleep states) which may not be needed in minimum configuration
  • Java - Need a good Java story
    • Oracle has stated that v8 support will be available, but timing and licensing is currently unknown
    • LEG SC LEG SC would like to see a robust and optimized open source Java solution, given the criticality of JAVA for the target workloads
    • on ARM v7 Oracle JVM vs OpenJDK has a huge perf boost + OpenJDK lacks several JNI's. Plus nobody actively working on it. On ARM v7 it is not viable option. On v8 maybe?
    • OpenJDK is 10-20% slower vs Sun JVM on x86
    • Kiko asked if target customers would accept solutions based on OpenJDK
    • Tim stated that there is an opportunity to provide a new and different solution for ARM servers, so target customers may be open to OpenJDK if it is a performant solution
    • Jeff suggested that OpenJDK is currently a Front-End and Back-end based compiler solution. Perhaps we could leverage LLVM and simplify the OpenJDK solution for ARM servers.
    • We may need to port the OpenSource JIT for x86 to ARM (coincidentally this is similar to the work required for HipHop)

    • Ali suggested that we need an assessment of the work that will be required. Code generation, binary translation and dynamic compilation are the core skillsets.
    • Jon update on OpenJDK status
      • There is no JIT yet...
      • Working on C1, then will move to C2
      • Action - Suggested that we get Andrew Halley to provide an update to LEG and Linaro on the work required
      • 2 resources currently... Requires 2 rockstars, and 2 years... can this be accelerated?
      • Would like to see LEG assist the OpenJDK effort
      • Target is to do a full C2 Aarch64 JIT with performance on par with Oracle
    • Ali mentioned that we should collaborate on HipHop and OpenJDK efforts

      • don’t think we’d be able to share any code, but we can benefit by sharing experience with dynamic code generation/optimization for ARM. The work between HipHop and OpenJDK will be similar as both will build a new JIT compiler code generator target.

Card Review

  • CARD-269 NUMA

    • 32-bit done, need to track the upstreaming phase via CARD-339

    • add plan for 64-bit
  • CARD-227 System level workloads

    • summarizes the initial work performed by the LEG SC to outline workload/vertical targets for ARM servers.
    • This Card will be closed in favor of setting up unique cards for each vertical
  • CARD-229 Hadoop HDFS CRC32

    • review and streamlining CRC32 for Hadoop HDFS usage on ARM servers. This is specific to v7, an additional card will be created to handle v8 (which will use a different algorithm).
    • To be reviewed by Steve Capper and Rob Herring, who will involve the right person at Calxeda
      • Larry requested that Cards show the configuration details, given the complexity
  • CARD-328 web/cache

    • caching as a separate epic card, because the code is really very different
  • Card 330 - Machine Check Exception (MCE)

    • discussion regarding the need for error checking on Linux ARM platforms. MCE Log is the mechanism used for x86. MCE Log uses SMBIOS.
    • Jon suggested discussing at the April Linux Collaboration forum, so that this can be discussed with Intel as well.
    • Need to understand management frameworks used by Hyperscale customers and what error logging they ‘expect’ - EDAC / MCE / Other?
    • Maybe an option to use EDAC but expose data in MCE format to support existing management frameworks.
    • MCE has huge alarm reporting, which one is really needed in ARM servers?
    • ACTION for Tim/Ali to share their view
    • it is a foundation work for all ARM servers and shall be done before LEG members design and deploy their proprietary custom implementations
  • CARD-173 GRUB on ARMand subcards eg CARD-262 GRUB on UEFI

    • All cards will stay open until patches are sent upstream. This allows for upstream feedback and requests to be reflected in each card during development.
    • Actually such cards will be composed of several sub tasks amongst which one will be dedicated to the upstreaming. All sub tasks will then be closed but the last one. The parent card will report a progress status of about 90-95% indicating that only upstream acceptance is missing.
  • CARD-174 UEFI / PXE boot

    • Rob: why not target QEMU for v7 - this aligns with Fast models, Versatile Express & Highbank

      • Anmar to look into this.
    • UEFI runtime services (subset - estimate ~5) will be needed to support the services the distro’s want (installer support etc...)
      • Need to define the subset and capture in the card - LKML post “what Linux cares about” on this exists - Jon & Kiko to come up with

      • Capture end goal in card - grub / kernel install under UEFI - ‘Grub install’ needs to work on ARM based systems.
  • CARD-214 QEMU/KVM v8 epic and all sub cards CARD-215 CARD-221 CARD-217

    • Review in the following order: 214 then 215 - 221 - 217.
    • Suggested phasing:

Actions from this meeting

#

Action

Owner

Status

1

Solicit power management guidance from HP, FaceBook, other OEMs on the desired ACPI states

Tim, Ali, etc.

OPEN

2

Invite Andrew Haley to provide an update to LEG and Linaro on openJDK

Jon, Andrea

OPEN

3

invite Owen to join LAVA learning curve with Fu Wei

Andrea

OPEN

4

Organize a BOF session on JIT and code generators at LCA13

Andrea

OPEN

5

Promote clarification of PXE in UEFI card + feedback from Jon/Kiko

Anmar

OPEN

6

evaluate if KVM mini summit possible e/o January - early February

Ilias

OPEN

7

add the snapshot date on each roadmap update

Andrea

OPEN

8

estimate tentative date for UEFI on v8 and add to the roadmap

Anmar, Andrea

OPEN

9

identify minimal subset of MCE alarm reporting

Tim, Ali

OPEN

LEG-SC/2013-01-15 (last modified 2013-03-22 19:09:04)