LEG BUD17 Session Slides

Session 1

Bluejeans Live Stream

https://bluejeans.com/s/uLe4t

Attendees

Gary Yurcak - QC

Sean Campbell - QC

Elsie Wahlig - QC

Jon Masters - Red Hat

Scott ? - Red Hat

Jeff Underhill - ARM

Mark Hambleton - ARM

Thomas Molgaard (remote) - ARM

David Brash - ARM

Dong Wei - ARM

Tony Chen - ARM

Charles Garcia-Tobin - ARM

Andrea G - Linaro

George G - Linaro

Martin Stadtler - Linaro

Mark Orvek - Linaro

David Rusling - Linaro

Gema Gomez - Linaro

Graeme G - Linaro

Ganesh Raju - Linaro

Anoop S - Linaro

Kanta Vekaria- LInaro

Bill Mills - TI

Grant Likely - HPE

Satoru Okamoto - Socionext

Kiyoshi Owada - Socionext

Larry Wikelius - Cavium

Roy Franz - Cavium

Minutes

Martin introduces new members.

Martin explains the agenda:

• Engineering priorities will be discussed tomorrow.

• Need to talk about the different ongoing projects (ERP, Developer Cloud, RPK).

• On Wed at 2pm, Huawei will be presenting acceleration.

• OpenJDK, current status, where are we, what are we doing? JDK 10 is coming up, what is the story around CI.

• Member presentations: martin will be asking members to present either Wednesday or Thursday

• OSCE: Jeff has a talk Monday at 5pm, in boardroom 2, we’ll have a short follow up conversation to discuss within the SC any concerns.

• LEG Breakfast is on Wed, RedHat will talk about their roadmap, under NDA, no random observers allowed. Breakfast will be in the same room as Monday’s 2pm meeting according to Martin.

• Smaller breakfast on Thursday to cover DPDK and LuaJIT, around maintainership.

• SocioNext is coordinating a demo in the hacker room.

• On Demo day we’ll have DPDK demo and Ambari demo.

Mark Hambleton presentation - Server software support: How do we make it really real?

Problem statement

Lots of server platforms in varied levels of development, early adopters expecting the same level of support as x86.

Firmware is immature, upstream has several levels of support, kernel features are in development and somewhat disconnected, distros have varies levels of support and engagement with the vendors.

Solutions

We need to look at

• firmware validation and cert

• kernel integration and validation

• rich use case validation and Distros

• How we expose known good version combinations of the above

• Upstream

• Getting end customers involved: OS vendors, OEMs are not represented

Jeff Underhill presents for 3 Phases of platform validation & enablement

phases of marker readiness

• Bring-up

• interop

• 0 day process for patches

• regression testing to ensure we don’t break things

• IHV enablement

• Documenting the explicit platform and OS combinations

• Avoid developer / end customer access during this phase

• Pre-production

• start to integrate things like virtualization, containers

• orchestration, management, monitoring, deployment

• diversity and capacity of the HW at this stage, make sure we have sufficient hardware

• start developing customer engagements

• Production

• go into user space and more complex environments

Charles presents on Solutions - Firmware

• create a validation suite to enable a vendor to certify their firmware and hardware

• SBSA / SBBR compliance

• ACPI tables need to be validated, not happening now

• FWTS / LuvOS / Grub validation already in flight

• Validate firmware can:

• boot the upstream kernel

• enable virtualization

• boot a defined set of distro releases

• Publish results

Mark H presents Solutions - kernel

• form a kernel upstream working group

• each SOC vendor and ARM disclose their kernel feature plans

• discuss how to align releases on common features to enable a feature to work for everyone

• publish links to patches for integration into a common test kernel for multiple platform

• create and maintain common test kernel

• branch the latest released kernel

• establish CI which will test state of this branch before any patch is applied (gerrit/jenkins flow)

• Apply / fix patches from vendor kernels successively until the common kernel includes all the latest vendor patches - merge and integrate where necessary (foundation for 0-day testing?)

• weekly regression testing with wider set of use cases than smoke tests

• publish weekly / monthly builds with certified firmware

Jon Masters is opposed to the idea of having a separate from upstream kernel. Mark wants this to be an accelerator and wants to get all those patches upstream. We need to make sure we don’t get kicked out of the tree by breaking next. The maintainers shouldn’t have to think about anything other than integrating our patches.

Larry ask that How do we move faster if what we struggle with is the superset, not the lowest common denominator? Anything we look at needs to look at the super set. How does this fix this problem? Mark responds that we cannot push non released spec’ed code upstream, there is a bunch of lower hanging fruit that we should be collaboratively doing here, the things ARM shares with Jon would make sense to share in this forum and the load could be spread. Sometimes there has been parallel development hitting upstream at the same time so we should be looking at deduplicating all this effort.

Elsie asks when we talk about moving from  the upstream, if we do it on linux next or in ARM linux next then we are shifting the problem from one place to another. Mark replies that right now everybody has their own kernel. Elsie wants people to look upstream, that’s the only thing that matters. Mark replies that for the newest features there is not one place where customers can go and use that kernel, whilst these features are making it upstream. Distro kernels are good at catching up, but the features need to be upstream.

? says having a pre-integration tree is extremely valuable. Having pre-integration where trees can then show up in ARM linux next and then into linux next. Mark goes back to the presentation, only 5 mins next.

Multiple levels of validation are going to be necessary. We should be focusing on upstream, our focus is to accelerate upstream, but let’s make the process slicker. However we do it we need to have a single kernel that supports all the features. Jon qualifies that there is a difference between pre-validation of patches that go into the next kernel, vs customizations that are not fully ready, Jon would strongly push back on customizations that are not ready for upstream.

End customers, where are they? Need to get the OEM involved as well.

ARM asks:

within linaro the LEG-SC should establish a codeline, firmware validation farm, find a way to publish the results per platform, find a way to get the ODMs and OEMs involved in this, integration IHV testing, turn this into a plugfest, then define a feedback process. How do we get the feedback back to the people interested in the problems? ARM will sit with mr Orvek and try to figure out how to source all of this. Charles(?) will be setting up a certification lab. That should cover HW and firmware.

What are you guys going to do?

Session 2

https://bluejeans.com/s/xlXsd/

Attendees

Gary Yurcak - QC

Sean Campbell - QC

Elsie Wahlig - QC

Jon Masters - Red Hat

Scott ? - Red Hat

Jeff Underhill - ARM

Mark Hambleton - ARM

Thomas Molgaard (remote) - ARM

David Brash - ARM

Dong Wei - ARM

Tony Chen - ARM

Charles Garcia-Tobin - ARM

Martin Stadtler - Linaro

Gema Gomez - Linaro

Graeme G - Linaro

Ganesh Raju - Linaro

Anoop S - Linaro

Kanta Vekaria- LInaro

Bill Mills - TI

Grant Likely - HPE

Satoru Okamoto - Socionext

Kiyoshi Owada - Socionext

Larry Wikelius - Cavium

Roy Franz - Cavium

Minutes

Martin started with Resource allocation which include LEG & Core Eng

LEG 14 dedicated (4 Linaro & 10 AE) and 46 Member Engineers

Core Eng teams include Virtualization, Kernel, Security, Toolchain, Lava, Linaro Lab, QA

Request members to review LEG SC Engineering Prioritization for resources

Question who is doing Integration work & decide which patch to take. And every 6 months is slow

Martin: General align with other open source releases

Jon: All distros have a rolling cutting edge version which can be used to get the current state of most projects OpenJDK eg.

Elsie: Pre-integration  before upstream

Jon: Linaro can partner with ARM/ecosystem and work with distros on their cutting edge rolling distros. Better than constantly revving the ERP.

Martin: Patches coming from different vendors clashes on integration and we need to have resources, despite we have right amount of hardware. And we are focusing for next 6-8 months for automation

Elsie/Gary: ERP needs to be more often what does this require?

Automation require hardware and people

Elsie: Kernel release is typically 8 weeks

Martin: Like to to do release with every kernel release cycle, but not possible with current available resource. May comeup with a proposal before end of connect

Challenge is that every vendor picks different kernel release

Jon: OK with 6 months ERP, but have all latest upstream

Please have a look at this slidedeck and spreadsheet (LEG SC Engineering Prioritization ) for tomorrow (Wednesday) meeting

Martin discuss high level efforts for Server Arch, SDI, BigData & OpenJDK inside LEG

Larry:  Do we have Core engineering priorities

Session 3

https://bluejeans.com/s/W2GKi/

Attendees

Gary Yurcak - QC

Sean Campbell - QC

Elsie Wahlig - QC

Jon Masters - Red Hat

Scott ? - Red Hat

Jeff Underhill - ARM

Mark Hambleton - ARM

Thomas Molgaard (remote) - ARM

David Brash - ARM

Dong Wei - ARM

Tony Chen - ARM

Charles Garcia-Tobin - ARM

Sean (Remote)

Wade Tregaskis (remote)

Martin Stadtler - Linaro

Gema Gomez - Linaro

Anoop S - Linaro

Kanta - Linaro

Bill Mills - TI

Satoru Okamoto - Socionext

Kiyoshi Owada - Socionext

Larry Wikelius - Cavium

Grant LIkely - HPe

Roy Franz - Cavium

John Garry - HiSilicon

Minutes

John Garry started presentation for Hardware Accelerator for ARM64 Servers

Will focus on ecosystem for Hardware accelerators.

Looking for idea to make Hardware accelerators better

Quest: Is issue when introducing a scheduling ?