Linaro Connect Bangkok

Google has released gVisor in 9 months ago, a new kind of sandbox that can be used to provide secure
isolation for containers that is less resource intensive than running a full virtual machine (VM).

At its core, gVisor is an open source user-space kernel, written in Go,
that implements a substantial portion of the Linux system surface.
It includes an Open Container Initiative (OCI) runtime called runsc that provides an isolation boundary between the application and the host kernel.
The runsc runtime integrates with Docker and Kubernetes, making it simple to run sandboxed container.

Now, we have enabled gVisor ptrace platform on Arm64 platform. In this presentation, we will introduce and show our progress.
Also we will show a demo of gVisor on Arm64 platform.

Introduce the latest status of storage related open source projects on aarch64 platform.
Supports Ceph enabling SPDK on aarch64 with 4KB and 64KB kernel page size, patches are accepted on Ceph, SPDK and DPDK upstream.
Extends ISA-L library to supports aarch64 platform and offer the unique common library for storage related projects and boost the performance in aarch64 ecosystem. It includes the optimization on compression, hash, crypto, data integrity, data protection and so on.

The Arm Architecture is continually evolving as new features and enhancements are developed to meet existing market demand, and to enable new markets. Arm, Linaro, and the wider Arm ecosystem build on the core Architecture, creating a rich and varied range of products along with associated Firmware and Software, to drive the technologies of the future.

This presentation will reveal the culmination of several years of new architecture development, intended to benefit both Client & Server systems.

It will discuss the software enablement that is currently taking place, and the future development needs for the wider ecosystem, to ensure that software is in place and ready to support these features when the devices become available.

Hosted by the Board chairs for the Trusted Firmware community project, this will be an update of development progress for Trusted Firmware M and Trusted Firmware A

Modern CI/CD systems receive a wide variety of workloads, everything from quick jobs with simple dependencies that take less than a minute all the way up to full operating system rebuilds that can take hours or days. The needs of the software developer for quick turnaround of routine jobs are balanced against the system architect's expectation that expensive systems should not see undue amounts of idle time.

This analysis looks at the challenges faced by a CI/CD system that incorporates a variety of machines of varying capacities, hosted by different organizations, where the individual systems themselves have varying degrees of parallel compute capabilities. We identify several real-world systems - NixOS's "nixpkgs", the FreeBSD build system, the LLVM build farm, and others - to pick out some important considerations.

The Works on Arm cluster is run by Packet for Arm to provide test, development, and data center CI/CD resources for community projects to build on arm64. The project also includes a weekly video office hours, a weekly newsletter, and a channel on the Packet Community Slack and Freenode IRC (#worksonarm) for community discussion.

This BOF session will provide current and future users of the cluster an opportunity to discuss technical issues regarding integration, testing, Cloud Native and network workloads, and generally provide a forum for helping set the direction of the effort in the coming year.

The BOF leader, Ed Vielmetti, is director of the Works on Arm project.

We've heard what you've said and we're making a series of significant changes to our Developer and Community websites to help you learn, develop, and collaborate on Arm.

Join us to explore the new ways you can connect with our developer content and help us discover what works, and what doesn't, about our updated Arm Developer journeys.

Based upon targeted microbenchmarks and SpecJVM, AArch64 Java AOT performance is compared against Xeon. Sweeping conclusions prove difficult to draw, but tantalizing hints about performance differences emerge.