Forem: Jason Andrews

AWS Graviton migration with Kiro CLI and the Arm MCP server

Jason Andrews — Mon, 12 Jan 2026 23:46:59 +0000

AWS Graviton processors offer price-performance benefits, but migrating applications from x86 to the Arm architecture can feel like extra work. You might wonder about compatibility issues, performance implications, or simply where to start with the migration process.

The Arm MCP server paired with Kiro CLI makes a good migration companion. Instead of manually researching compatibility matrices, hunting through documentation, or guessing about architecture-specific dependencies, you get an AI assistant that understands Arm migration.

This article explains how to set up Kiro CLI with the Arm MCP server and discover how it transforms migration questions into simple conversations. You'll see how to verify Docker image compatibility, get guidance on software porting considerations, and leverage tools that detect x86-specific code in your applications.

By the end, you'll have an environment that makes Graviton migration feel less like detective work. Whether you're planning your first migration or optimizing an existing Arm deployment, this setup will save time and increase confidence in the migration process.

Quick setup

Before diving into Graviton migration, you need Kiro CLI installed on your system.

Before installing Kiro CLI, make sure you have unzip installed.

For Ubuntu run:

sudo apt install unzip -y

Use the package manager for other Linux distributions or Homebrew on macOS.

Installing Kiro CLI

The fastest way to get Kiro CLI running is with a single curl command that handles the entire installation process. This method works seamlessly on both Arm Linux and macOS systems.

curl -fsSL https://cli.kiro.dev/install | bash

The installer will download the appropriate version for your system and prompt you about updating your shell configuration.

If you're on macOS you can use Homebrew as an alternative installation option:

brew install kiro-cli

Verifying your installation

Once the installation completes, confirm everything is working by checking the version:

kiro-cli version

You should see output similar to this:

kiro-cli 1.23.1

This confirms Kiro CLI is properly installed and ready to use. The version number may be different depending on when you install it, but seeing any version output means you're good to proceed.

Docker prerequisite

You'll also need Docker running on your system since the Arm MCP server runs as a containerized service. If you don't have Docker installed yet, you can download it from the Docker website. The Arm MCP server image will be pulled automatically during the configuration step, so you don't need to download anything manually right now.

If you are running on Linux, you can use the simple install:

curl -fsSL get.docker.com -o get-docker.sh && sh get-docker.sh
sudo usermod -aG docker $USER ; newgrp docker

MCP server configuration

Now that Kiro CLI is installed, you need to connect it to the Arm MCP server that provides the specialized knowledge and tools for Graviton migration. This server runs as a Docker container and integrates with Kiro CLI through a simple configuration file.

Setting up the Arm MCP server

The Arm MCP server comes pre-packaged as a Docker image. Pull the latest version with this command:

docker pull armlimited/arm-mcp:latest

This downloads the container image, which includes the Arm-specific knowledge base, migration tools, and compatibility databases you'll need for your Graviton migration projects.

Configuring the connection

Kiro CLI connects to MCP servers through a configuration file that defines how to launch and communicate with each server.

Create the configuration directory and file:

mkdir -p ~/.kiro/settings

Use an editor to create the MCP configuration file at ~/.kiro/settings/mcp.json with this content:

{
  "mcpServers": {
    "arm_mcp_server": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "--pull=always",
        "-v", "/home/ubuntu:/workspace",
        "--name", "arm-mcp",
        "armlimited/arm-mcp:latest"
      ],
      "env": {},
      "timeout": 60000
    }
  }
}

This configuration tells Kiro CLI to launch the Arm MCP server using Docker with several important settings. The --pull=always flag ensures you're always using the latest version of the server, while the volume mount (-v /home/ubuntu:/workspace) gives the server access to your directory so it can analyze your codebase directly. You can modify the mounted directory for your project.

Understanding volume mounting

The volume mounting is important for migration work. When you run Kiro CLI from within a project directory, the Arm MCP server can examine your actual code files, Dockerfiles, dependency manifests, and build configurations. This enables it to provide specific recommendations about your codebase rather than general migration advice.

For example, if you're working on a Node.js application and run Kiro CLI from your project root, the server can analyze your package.json file to identify potentially problematic dependencies or suggest Arm-optimized alternatives.

Verification and connection testing

With your configuration in place, it's time to verify that everything is working correctly. This verification process ensures both Kiro CLI and the Arm MCP server are properly connected and ready for your migration work.

Start Kiro CLI to initiate the connection to the Arm MCP server:

kiro-cli

The first startup may take a moment as Docker starts the container and initializes the connection. You'll see Kiro CLI's prompt once everything is ready:

⚠ 0 of 1 mcp servers initialized. Servers still loading:
 - arm_mcp_server
⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀     ⢀⣴⣶⣶⣦⡀⠀⠀⠀⢀⣴⣶⣦⣄⡀⠀⠀⢀⣴⣶⣶⣦⡀⠀⠀⢀⣴⣶⣶⣶⣶⣶⣶⣶⣶⣶⣦⣄⡀⠀⠀⠀⠀⠀⠀⢀⣠⣴⣶⣶⣶⣶⣶⣦⣄⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀    ⢰⣿⠋⠁⠈⠙⣿⡆⠀⢀⣾⡿⠁⠀⠈⢻⡆⢰⣿⠋⠁⠈⠙⣿⡆⢰⣿⠋⠁⠀⠀⠀⠀⠀⠀⠀⠀⠈⠙⠻⣦⠀⠀⠀⠀⣴⡿⠟⠋⠁⠀⠀⠀⠈⠙⠻⢿⣦⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀    ⢸⣿⠀⠀⠀⠀⣿⣇⣴⡿⠋⠀⠀⠀⢀⣼⠇⢸⣿⠀⠀⠀⠀⣿⡇⢸⣿⠀⠀⠀⢠⣤⣤⣤⣤⣄⠀⠀⠀⠀⣿⡆⠀⠀⣼⡟⠀⠀⠀⠀⣀⣀⣀⠀⠀⠀⠀⢻⣧⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀    ⢸⣿⠀⠀⠀⠀⣿⡿⠋⠀⠀⠀⢀⣾⡿⠁⠀⢸⣿⠀⠀⠀⠀⣿⡇⢸⣿⠀⠀⠀⢸⣿⠉⠉⠉⣿⡇⠀⠀⠀⣿⡇⠀⣼⡟⠀⠀⠀⣰⡿⠟⠛⠻⢿⣆⠀⠀⠀⢻⣧⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀    ⢸⣿⠀⠀⠀⠀⠙⠁⠀⠀⢀⣼⡟⠁⠀⠀⠀⢸⣿⠀⠀⠀⠀⣿⡇⢸⣿⠀⠀⠀⢸⣿⣶⣶⡶⠋⠀⠀⠀⠀⣿⠇⢰⣿⠀⠀⠀⢰⣿⠀⠀⠀⠀⠀⣿⡆⠀⠀⠀⣿⡆
⠀⠀⠀⠀⠀⠀⠀    ⢸⣿⠀⠀⠀⠀⠀⠀⠀⠀⠹⣷⡀⠀⠀⠀⠀⢸⣿⠀⠀⠀⠀⣿⡇⢸⣿⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣠⣼⠟⠀⢸⣿⠀⠀⠀⢸⣿⠀⠀⠀⠀⠀⣿⡇⠀⠀⠀⣿⡇
⠀⠀⠀⠀⠀⠀⠀    ⢸⣿⠀⠀⠀⠀⠀⣠⡀⠀⠀⠹⣷⡄⠀⠀⠀⢸⣿⠀⠀⠀⠀⣿⡇⢸⣿⠀⠀⠀⠀⣤⣄⠀⠀⠀⠀⠹⣿⡅⠀⠀⠸⣿⠀⠀⠀⠸⣿⠀⠀⠀⠀⠀⣿⠇⠀⠀⠀⣿⠇
⠀⠀⠀⠀⠀⠀⠀    ⢸⣿⠀⠀⠀⠀⣾⡟⣷⡀⠀⠀⠘⣿⣆⠀⠀⢸⣿⠀⠀⠀⠀⣿⡇⢸⣿⠀⠀⠀⠀⣿⡟⣷⡀⠀⠀⠀⠘⣿⣆⠀⠀⢻⣧⠀⠀⠀⠹⣷⣦⣤⣤⣾⠏⠀⠀⠀⣼⡟
⠀⠀⠀⠀⠀⠀⠀    ⢸⣿⠀⠀⠀⠀⣿⡇⠹⣷⡀⠀⠀⠈⢻⡇⠀⢸⣿⠀⠀⠀⠀⣿⡇⢸⣿⠀⠀⠀⠀⣿⡇⠹⣷⡀⠀⠀⠀⠈⢻⡇⠀⠀⢻⣧⠀⠀⠀⠀⠉⠉⠉⠀⠀⠀⠀⣼⡟
⠀⠀⠀⠀⠀⠀⠀    ⠸⣿⣄⡀⢀⣠⣿⠇⠀⠙⣷⡀⠀⢀⣼⠇⠀⠸⣿⣄⡀⢀⣠⣿⠇⠸⣿⣄⡀⢀⣠⣿⠇⠀⠙⣷⡀⠀⠀⢀⣼⠇⠀⠀⠀⠻⣷⣦⣄⡀⠀⠀⠀⢀⣠⣴⣾⠟
⠀⠀⠀⠀⠀⠀⠀    ⠀⠈⠻⠿⠿⠟⠁⠀⠀⠀⠈⠻⠿⠿⠟⠁⠀⠀⠈⠻⠿⠿⠟⠁⠀⠀⠈⠻⠿⠿⠟⠁⠀⠀⠀⠈⠻⠿⠿⠟⠁⠀⠀⠀⠀⠀⠈⠙⠻⠿⠿⠿⠿⠟⠋⠁

╭─────────────────────────────── Did you know? ────────────────────────────────╮
│                                                                              │
│   If you want to file an issue to the Kiro CLI team, just tell me, or run    │
│                                kiro-cli issue                                │
│                                                                              │
╰──────────────────────────────────────────────────────────────────────────────╯

Model: Auto (/model to change)


>

Now verify the Arm MCP server connection by listing its available tools:

/tools

You should see output listing the available MCP server tools. The exact tool names and descriptions may vary slightly depending on the version, but you should see several tools related to Arm migration and compatibility analysis.

This output confirms that Kiro CLI has successfully connected to the Arm MCP server and can access all its migration tools.

Knowledge base exploration

Now that you have Kiro CLI connected to the Arm MCP server, let's explore its knowledge capabilities through some migration scenarios. Rather than diving straight into code analysis, you'll start by asking the kinds of questions that come up during real migration planning sessions.

With this setup, you can have natural conversations about technical topics. Instead of hunting through documentation or trying to piece together information from multiple sources, you ask your questions and get Arm-focused answers.

Understanding Graviton software porting considerations

Let's start with a fundamental question that every migration project faces:

What are the key software porting considerations when migrating applications to AWS Graviton processors?

The Arm MCP server provides a detailed response covering the essential areas you need to evaluate. The response includes guidance on dependency compatibility, performance optimization opportunities, and common migration patterns. You'll receive specific recommendations about compiler flags, library alternatives, and testing strategies that apply directly to your Graviton migration project.

This response demonstrates the MCP server's understanding of migration challenges and provides actionable guidance you can immediately apply to your projects. Notice how it covers both technical requirements and practical implementation considerations.

Checking software compatibility

You can also ask about specific software and check if it's available on Graviton.

For teams working with Microsoft technologies, .NET compatibility is often a primary concern:

What versions of .NET are compatible with AWS Graviton processors, and are there any specific considerations for .NET applications?

The server provides specific version information and migration guidance. You'll receive details about .NET 6 and later versions' native Arm64 support, performance optimization recommendations, and guidance on handling dependencies that may need attention during migration. You can even ask for a recommended version and find out that it may be better to go with .NET 8 because it has a longer support window compared to .NET 9.

This level of detail helps you make informed decisions about software versions.

Getting Aperf installation guidance

For performance analysis and optimization work, you might need specialized tools:

How do I install and use Aperf for performance analysis on AWS Graviton instances?

The server provides installation and usage guidance. You'll receive step-by-step installation instructions and configuration recommendations on Graviton instances.

These three examples show the breadth and depth of knowledge available through the Arm MCP server. Whether you're planning a migration, troubleshooting compatibility issues, or optimizing performance, you have access to a knowledge base tailored for Arm and Graviton environments.

Advanced migration tools

Beyond answering migration questions, the Arm MCP server provides tools that analyze your actual codebase and infrastructure configurations. These capabilities transform abstract migration advice into concrete, actionable recommendations specific to your project.

Dockerfile analysis

One of the most useful tools for containerized applications is the Dockerfile compatibility checker. Instead of manually reviewing your container configurations for Arm compatibility issues, you can get automated analysis with specific recommendations.

When you have a Dockerfile in your current project directory, you can ask the MCP server to analyze it for potential Arm compatibility issues. The server examines your Dockerfile and provides detailed feedback about base image compatibility, identifies potential problems like x86-specific binaries or native libraries, and suggests optimization opportunities for multi-architecture builds.

This analysis saves time and provides specific line-by-line guidance. The MCP server understands common patterns that cause Arm compatibility issues and suggests practical solutions that fit into existing development workflows.

x86-specific dependencies

For applications with complex dependency trees, the server can scan your codebase to identify potentially problematic x86-specific dependencies before you encounter runtime issues.

The server can analyze your project files and dependency manifests to identify compatibility concerns across your entire technology stack. It examines package files, build configurations, and scripts to flag dependencies that may need attention before moving to Graviton. The analysis provides specific version recommendations and alternative packages, along with estimated migration effort, making the migration process more predictable.

Conclusion

You've learned how Kiro CLI paired with the Arm MCP server transforms AWS Graviton migration into a guided conversation that makes it easier to get started.

The setup you've completed gives you access to migration knowledge, from high-level architectural considerations to specific dependency compatibility issues. The automated tools for Dockerfile analysis and x86 dependency detection catch potential problems before they impact your deployment timeline, while the knowledge base provides context and solutions for the challenges you'll encounter.

The combination of conversational AI assistance and analysis tools represents a shift in how migration projects can be approached. You can now iterate quickly, validate assumptions immediately, and make informed decisions with confidence.

Get started with AWS T4g instances

AWS T4g instances powered by Graviton processors are available in the AWS Free Tier through December 31, 2026. This gives you an extended opportunity to test your applications, validate performance improvements, and gain hands-on experience with Graviton without incurring costs.

The free tier includes 750 hours per month of t4g.micro instances, providing ample time to experiment with your migration workflow and validate the guidance you receive from the Arm MCP server. You can use this to test containerized applications, benchmark performance differences, and refine your migration approach before committing to production deployments.

For complete details about T4g instance specifications and free tier eligibility, visit the AWS T4g instances page.

Ready to dive deeper into Arm development and migration capabilities? The Arm MCP server offers additional tools and knowledge bases that can accelerate your Graviton adoption journey. Explore the documentation, examples, and features to continue learning.

Improve Performance with 64K Memory Pages on AWS Graviton Processors

Jason Andrews — Fri, 28 Nov 2025 03:38:02 +0000

If you're running memory intensive workloads on AWS Graviton processors, you may want to investigate 64K pages. One commonly overlooked optimization is switching from the default 4K memory pages to 64K pages. This kernel configuration change can reduce memory management overhead and improve performance for some workloads.

This article explains what memory pages are and shows how to switch between 4K and 64K pages on Ubuntu 24.04.

What Are Memory Pages?

Memory pages are the standardized containers used to organize and move data around. The operating system and the CPU's Memory Management Unit (MMU) use a page table to track which virtual memory addresses map to physical RAM locations. This is how operating systems like Linux provide virtual memory that is larger than the physical memory of the system.

To speed up these lookups, CPUs use a fast cache called a Translation Lookaside Buffer (TLB). Every memory access first checks the TLB. If the mapping isn't there (a TLB miss), the CPU must perform a "page table walk" to fetch it from main memory, which can involve multiple memory accesses and add latency.

On x86 systems, 4K pages are standard. AWS Graviton processors support multiple page sizes. The Arm architecture supports 4K, 16K, and 64K pages, but Linux distributions typically support 4k and 64k. This flexibility lets you optimize for your specific workload.

NOTE: If you want to try 16K pages you can run Asahi Linux on Apple Silicon.

The Performance Impact of Page Size

Changing page size creates a cascading effect on system performance:

With 4K pages, you need more TLB entries to map the same amount of memory. This increases TLB misses and page-table-walk overhead. With 64K pages, each TLB entry covers 16x more memory, which reduces TLB pressure and can improve TLB hit rates.

Disk I/O and DMA operations often perform better with larger pages because fewer page boundaries are crossed during transfers. This means fewer interrupts and larger DMA bursts.

The kernel's page management structures scale with the number of pages. Fewer pages mean less memory spent on bookkeeping.

The drawback of larger pages is that for small, varied allocation patterns, more memory is consumed. This is known as internal fragmentation. For example, if a 2KB process is allocated a 64K page, 62KB of that page's memory is wasted.

A Note on Huge Pages vs. Base Page Size

It's important to distinguish the 64K page size on Arm from the "Transparent Huge Pages" (THP) feature in Linux. THP is a system that tries to dynamically allocate large 2MB pages on top of a standard 4K base page size. The 64K page support on Graviton changes the base page size for all memory management, which is a fundamental, system-wide setting.

Which Workloads Benefit from 64K Pages?

64K pages are most effective for applications that work with large, contiguous memory regions:

Databases: Large buffer pools and cache systems (PostgreSQL, MySQL, Redis)
Big Data Processing: Spark, Hadoop, and data analytics workloads
Machine Learning: Training and inference with large datasets
Video Processing: Encoding, transcoding, and streaming applications
High-Performance Computing: Scientific simulations and numerical computing
In-Memory Caching: Memcached, Redis with large datasets

Conversely, stick with 4K pages for:

Web servers handling many small requests
Microservices with small memory footprints
Applications with highly fragmented memory access patterns

How to Switch to 64K Pages on AWS Graviton

You can experiment with 64K pages in a non-production environment to see if they help your applications.

Ubuntu 24.04 on AWS Graviton

Ubuntu makes this easy with a pre-built 64K kernel package.

Step 1: Check your current page size

getconf PAGESIZE
uname -r

You should see:

4096
6.14.0-1016-aws

Step 2: Install the 64K kernel

sudo apt-get update
sudo apt-get install -y linux-generic-64k

Step 3: Configure GRUB to use the 64K kernel by default

echo "GRUB_FLAVOUR_ORDER=generic-64k" | sudo tee /etc/default/grub.d/local-order.cfg
sudo update-grub
sudo reboot

Step 4: Verify the change

After reboot:

getconf PAGESIZE
uname -r

You should now see:

65536
6.8.0-48-generic-64k

To revert to 4K pages:

echo "GRUB_FLAVOUR_ORDER=generic" | sudo tee /etc/default/grub.d/local-order.cfg
sudo update-grub
sudo reboot

You can find instructions for more Linux distributions in the Arm Learning Path Explore performance gains by increasing the Linux kernel page size on Arm.

Measuring the Impact

After switching to 64K pages, benchmark your application to measure the impact. Key metrics to monitor:

TLB miss rate: Use perf stat to measure TLB misses
Application throughput: Measure requests/second or transactions/second
Latency: Monitor p50, p95, and p99 latencies
Memory usage: Check for any increase in memory consumption

Performance Gains

Performance gains depend on the specific workload characteristics, but the potential gains make this optimization worth testing for suitable workloads.

Conclusion

AWS Graviton processors offer optimization opportunities not available on x86 systems. Switching to 64K memory pages is a kernel change that can deliver performance improvements for memory-intensive workloads without making any code changes.

It is important to understand your workload characteristics and test thoroughly. If you're working with large datasets, databases, or high-throughput applications on AWS Graviton, testing 64K pages is recommended.

If you are running AWS Graviton instances, make sure to check out the AWS Graviton Technical Guide for more optimization tips.

Create and run Windows on Arm virtual machines on AWS Graviton processors using QEMU and KVM

Jason Andrews — Tue, 11 Nov 2025 15:18:44 +0000

Windows application developers are currently adding support for the Arm architecture because they want to enable native app performance on new Windows on Arm Copilot+ PCs.

If you are looking for ways to build and test Windows on Arm software, you have several options to choose from. You can run Windows on Arm on a laptop, you can use cloud-based virtual machines, or you can leverage CI/CD platforms like GitHub Actions to access Windows on Arm.

Another option is to create Windows on Arm virtual machines directly on Amazon EC2 instances running AWS Graviton processors.

Read on to find out how to install and run Windows on Arm virtual machines on a Graviton-based EC2 instance. I have created two bash scripts to streamline the creation and management of your virtual machines.

Prepare your system for Windows on Arm virtual machines

Here are the steps you can use to run Windows on Arm on an Amazon EC2 instance:

Create an EC2 instance with AWS Graviton processors
Install and configure VNC
Confirm KVM is available
Install software dependencies
Create a Windows virtual machine
Run a Windows virtual machine

At the end, you will have a functional Windows desktop accessible using a VNC client from your local computer.

Create a bare-metal EC2 instance

You can use Graviton2, Graviton3, or Graviton4 processors. Graviton2 performance is sufficient for most Windows development. Use Graviton3 or Graviton4 if you want faster performance and features such as SVE2 (scalable vector extension), BFloat16 (16-bit floating point), and I8MM (8-bit integer multiplication).

In your AWS account, create a c6g.metal instance type and set up SSH connectivity running Ubuntu 24.04. Make sure to use at least 128 GB of storage to allow for virtual machine disk images. Each instance of Windows requires approximately 40 GB of storage. You can also use other bare-metal instances such as m6g.metal and r6g.metal.

To create the instance:

Launch a new EC2 instance from the AWS Console
Select Ubuntu Server 24.04 LTS as the AMI (make sure to select the Arm version)
Choose c6g.metal as the instance type
Configure a security group that allows SSH (port 22) from your IP address
Create or select an existing SSH key pair for authentication
In storage settings, allocate at least 128 GB for the root volume
Launch the instance and wait for it to enter the "running" state

Make sure you can SSH to the instance using your SSH key.

Confirm that you can access your instance and run:

sudo apt update

You are now ready to get started installing software.

Install and configure VNC

Virtual Network Computing (VNC) is a tool used to connect to a remote Linux desktop. Running Windows requires a desktop environment to see the installation process and to interact with the Windows desktop.

You can install VNC on your EC2 instance. VNC is a client-server application. A VNC server runs on a remote machine (the EC2 instance). A VNC client runs on the local machine (your laptop) and connects to the remote server.

Install the VNC server and xfce4 desktop

To use VNC, you need to install a VNC server on your EC2 instance. There are multiple VNC servers, one good option is TigerVNC.

You also need Linux desktop software. There are many options for this, but using xfce4 provides a minimal install with good performance.

Install the desktop software:

sudo apt-get install xfce4 xfce4-goodies xorg dbus-x11 x11-xserver-utils xfce4-terminal -y

Install the VNC server:

sudo apt-get install tigervnc-standalone-server tigervnc-common -y

Configure a VNC password

Run the vncpasswd command to set a password for VNC. This is not the password for your user account, but for the VNC client to connect to the VNC server.

vncpasswd

Remember the password for later when you connect the client.

Configure the desktop startup for VNC

Use a text editor to create a file named $HOME/.vnc/xstartup with the following contents:

#!/bin/sh
unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS
exec startxfce4

Give the file executable permission:

chmod +x $HOME/.vnc/xstartup

Set up a systemd service to manage VNC

To create a systemd service to start the VNC server, create the file /etc/systemd/system/vncserver@.service.

Use sudo or root privileges because this file is in a system directory.

Your username should be ubuntu, but if it is not, change the User value to match your username after you create the new file.

[Unit]
Description=Remote desktop service (VNC)
After=syslog.target network.target

[Service]
Type=simple
User=ubuntu
PAMName=login
PIDFile=/home/%u/.vnc/%H%i.pid
ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill :%i > /dev/null 2>&1 || : '
ExecStart=/usr/bin/vncserver :%i -localhost no -geometry 1440x900 -alwaysshared -fg
ExecStop=/usr/bin/vncserver -kill :%i

[Install]
WantedBy=multi-user.target

To start the VNC service:

sudo systemctl start vncserver@1.service

To stop the VNC service:

sudo systemctl stop vncserver@1.service

To restart the VNC service:

sudo systemctl restart vncserver@1.service

Use port forwarding via SSH to connect to VNC

The default port for the first instance of VNC is 5901. SSH port forwarding is a good solution for accessing the Linux desktop on a cloud machine. This way, no additional ports need to be opened in the security group.

SSH to your remote Linux machine.

Substitute your private key file and the public IP address of the remote machine in the following command:

ssh -i <private_key> -L 5901:localhost:5901 ubuntu@<public_ip_address>

Once connected via SSH, use a VNC client to connect. Download and install a TigerVNC client for your computer.

Open the VNC client and enter the following for the VNC server:

localhost:5901

You will be prompted for the password you created earlier with vncpasswd.

A remote Linux desktop should appear on your local computer. When you are finished, close the VNC client first and then exit the SSH connection.

Install other software dependencies

Next, install the software you need to create a Windows on Arm virtual machine using QEMU and KVM. Before installing the software, confirm KVM is available on your EC2 instance. A bare-metal Graviton instance is used so that KVM is available.

Verify KVM support

Kernel-based Virtual Machine (KVM) support is required for hardware-accelerated virtualization and optimal virtual machine (VM) performance on Arm systems. Without KVM, your VMs run significantly slower because they rely on software emulation instead of using Arm's hardware virtualization features.

KVM is a virtualization infrastructure built into the Linux kernel that allows you to run virtual machines with near-native performance. It leverages Arm's hardware virtualization extensions to provide efficient CPU virtualization, while QEMU handles device emulation and management.

Verify your system supports KVM by running:

sudo apt install cpu-checker -y
kvm-ok

If KVM is available, you will see the messages:

INFO: /dev/kvm exists
KVM acceleration can be used

This confirms that:

Your CPU supports hardware virtualization
The KVM kernel module is loaded
The /dev/kvm device exists

Add your user account to the KVM group:

sudo usermod -a -G kvm $USER
newgrp kvm

Install required software

The Windows on Arm scripts require several software packages.

Install the packages using the Linux package manager, including QEMU and Remmina, the remote desktop software used to connect to Windows VMs.

sudo apt update
sudo apt install qemu-system-arm qemu-utils genisoimage wget curl jq uuid-runtime seabios remmina remmina-plugin-rdp  -y

You now have the required software to create a Windows on Arm virtual machine on your EC2 instance.

Get started with the Windows on Arm VM automation scripts

A GitHub project provides two Bash scripts.

Start by cloning the project repository from GitHub to your Arm Linux system.

git clone https://github.com/jasonrandrews/win11arm.git
cd win11arm

The project includes two Bash scripts.

VM create script: create-win11-vm.sh handles all VM creation tasks
VM run script: run-win11-vm.sh manages VM execution and connectivity

All configuration is available using command-line options.

Create a new Windows virtual machine

To create a new VM, run the command:

./create-win11-vm.sh all $HOME/win11-vm

This single command executes all required virtual machine creation steps as explained in the previous section.

The VM data is stored in the $HOME/win11-vm directory, and Windows will install automatically without any user intervention.

The product key used in the scripts is a generic key provided by Microsoft, which allows installation. This key is for testing purposes only and does not activate Windows. If you plan to continue using Windows beyond installation, you should replace it with a genuine product key.

Once the VM creation is complete, you'll see:

QEMU closed successfully.
Windows installation should be complete!
You can now use: ./run-win11-vm.sh $HOME/win11-vm

Your Windows on Arm VM is now ready to use.

Run your newly created Windows 11 virtual machine

After your Windows 11 Arm VM is created, launching it is simple with the unified run script:

./run-win11-vm.sh $HOME/win11-vm

This single command handles the entire VM startup and connection process automatically.

The script performs three key steps. It does the following:

Checks if the VM is already running
Starts the VM in headless mode if required
Connects you through RDP using Remmina

When the virtual machine starts you will see it on your Linux desktop:

You now have a running Windows on Arm virtual machine running on an AWS Graviton-based EC2 instance.

VM shutdown

The preferred method is to shut down Windows normally from within the virtual machine.

Click the Start button in Windows
Select Power → Shut down
Wait for Windows to complete shutdown
The VM automatically stops when Windows finishes shutting down
Remmina exits automatically when the connection closes

You should avoid killing QEMU directly, as it may corrupt the VM disk. Also, avoid exiting Remmina prematurely, as it may leave the VM running in the background.

More details about command-line arguments and how the scripts work are available in Automate Windows on Arm virtual machine deployment with QEMU and KVM on Arm Linux.

Use the Amazon Q Developer CLI on AWS Graviton

Jason Andrews — Sat, 05 Apr 2025 16:10:16 +0000

Amazon Q Developer CLI is a command-line tool for Amazon Q, a generative AI-powered assistant. You can use it to ask questions about AWS architecture, resources, and general development tasks.

It supports multiple operating systems, including Arm-based Linux distributions, and runs on AWS Graviton processors.

What should I do before installing Amazon Q Developer CLI?

You need a Builder ID to use the Amazon Q Developer CLI. If you don't have one, visit Do more with AWS Builder ID and click Sign up with Builder ID to create your AWS Builder ID.

This guide explains how to install Amazon Q Developer CLI on macOS and Arm Linux distributions, such as Ubuntu and Amazon Linux 2023.

How do I download and install Amazon Q Developer CLI?

The CLI is invoked using the q command.

How do I install Amazon Q Developer CLI on macOS?

Install Homebrew if it's not already available on your computer.

Then install the Q CLI:

brew install amazon-q

How do I install the Q CLI on Arm Linux?

The easiest way to install the Q CLI on any Arm Linux distribution is to download and run the installer.

Before starting, ensure that curl and unzip are available on your computer.

For Debian-based distributions such as Ubuntu, use the commands below. For other Linux distributions, use the appropriate package manager to install curl and unzip.

sudo apt update
sudo apt install curl unzip -y

Download the zip file with curl:

curl --proto '=https' --tlsv1.2 -sSf "https://desktop-release.codewhisperer.us-east-1.amazonaws.com/latest/q-aarch64-linux.zip" -o "q.zip"

Extract the installer and run it:

unzip q.zip
bash ./q/install.sh

You'll then be prompted about updating your shell config:

✔ Do you want q to modify your shell config (you will have to manually do this otherwise)?

To automate the install, add the --no-confirm flag to the install.sh command.

If you're using a Linux distribution with an older version of the GNU C Library - or one that does not use it at all, such as Alpine - you can download an alternative package built with the musl C library and has no external dependencies.

Substitute the curl command above with this one and use the same install instructions:

curl "https://desktop-release.codewhisperer.us-east-1.amazonaws.com/latest/q-aarch64-linux-musl.zip" -o "q.zip"

How do I confirm the Q CLI is working?

You now have the latest version of the Amazon Q Developer CLI installed.

Confirm the CLI is available by invoking the q command to print the version.

q version

The version is printed:

q 1.7.2

How can I configure my AWS account to get the most from the Q CLI?

The Q CLI can answer questions and solve problems related to your AWS resources and help you develop faster on AWS. To get the maximum benefit, you can configure the AWS CLI to use your account.

Follow the AWS CLI Install Guide and the AWS Credentials Install Guide to set up the AWS CLI and generate and configure access keys.

This allows you to use the Amazon Q Developer CLI to ask questions and solve issues specific to your AWS account.

What is an example of using the Q CLI?

You can use q chat to find information about your AWS resources.

q chat

When the chat session starts you see:

Hi, I'm Amazon Q. Ask me anything.

Things to try
• Fix the build failures in this project.
• List my s3 buckets in us-west-2.
• Write unit tests for my application.
• Help me understand my git status

/acceptall    Toggles acceptance prompting for the session.
/profile      (Beta) Manage profiles for the chat session
/context      (Beta) Manage context files for a profile
/help         Show the help dialogue
/quit         Quit the application

For example, you can ask for the IP address of an EC2 instance instead of going to the AWS console or looking up the AWS CLI command to get it.

An example is shown below:

How can I set the Q CLI context to tailor responses?

The Q CLI reads your context when you start it. If you provide more information about yourself, you will get tailored responses that match your development environment.

There are multiple options to store context.

Use the /context command to see the possible locations to store your context.

/context show

The help information is printed.

current profile: default

global:
    .amazonq/rules/**/*.md
    README.md
    AmazonQ.md

For example, you can create a new file to store your context.

mkdir -p ~/.amazonq/rules/context
echo "I am an Arm Linux developer. I prefer Ubuntu and other Debian based distributions. I don't use any x86 computers so please provide all information assuming I'm working on Arm Linux. Sometimes I use macOS and Windows on Arm, but please only provide information about these operating systems when I ask for it." > ~/.amazonq/rules/context/context.md

When you invoke q chat you can confirm your context information was read by asking.

did you read my context information?

The response confirms the context file was read:

Yes, I've read your context information. I understand that you're an Arm Linux developer who prefers 
Ubuntu and other Debian-based distributions. You don't use x86 computers, so I should provide 
information assuming you're working on Arm Linux. You sometimes use macOS and Windows on Arm, but I 
should only provide information about those operating systems when you specifically ask for it.

I'll keep this context in mind when answering your questions, focusing on Arm Linux-specific 
information and Debian-based distributions by default.

Give it a try by asking questions such as how do I install the aws cli? and check that the answers match the provided context.

You're ready to use the Q CLI. For more AWS content, check out Arm Learning Paths.

Managed, self-hosted Arm runners for GitHub Actions using AWS Graviton Processors

Jason Andrews — Thu, 19 Sep 2024 03:44:34 +0000

What is GitHub Actions?

GitHub Actions is a popular CI/CD platform used to build, test, and deploy software directly from GitHub repositories. It supports a wide range of workflows, enabling you to define custom automation using YAML configuration files. With GitHub Actions, you can run workflows on various environments, including managed, self-hosted runners on cloud-based virtual machines like Amazon EC2.

Increasingly, software is being migrated to and developed on the Arm architecture. Managed, self-hosted Arm runners for Amazon EC2 using AWS Graviton processors is a great way to use GitHub Actions on Arm.

The three primary benefits of GitHub Actions on managed, self-hosted runners are:

Native performance: Execute build and test cycles directly on AWS Graviton processors. This eliminates the complexities associated with instruction emulation and cross-compilation.
Integrated Workflow: Experience a seamless integration within the familiar GitHub Actions environment without complexity infrastructure management.
Cost-effectiveness: Enjoy the convenience of GitHub Actions combined with the ability to select specific Graviton-based EC2 instance types for best price performance.

If you are interested in GitHub Actions on AWS Graviton processors, you can install RunOn, a self-hosted runner manager in your AWS account.

To do this, you will need an AWS account and a GitHub personal or organization account.

What is RunsOn for GitHub Actions?

RunsOn is a self-hosted runner manager for GitHub Actions that you can install in your own AWS account. It will automatically spawn EC2 VMs as self-hosted runners for your GitHub Actions workflows.

Runners are launched in less than 30 seconds, and you can select any of the instance types offered by AWS, including Arm instances with AWS Graviton processors. With Graviton processors, you can run GitHub Actions on Neoverse N1, Neoverse V1, and Neoverse V2 processors.

RunsOn is free for non-commercial projects. For commercial projects, a 15-day demo license is available (see pricing).

What do I need to use RunsOn in my AWS account?

You need the following to install RunsOn in your AWS account:

The name of your GitHub organization. If you are using a personal account, this is your GitHub username.
A license key. This is a string you obtain from RunsOn by e-mail.
An e-mail address you want to use to receive notifications from RunsOn.

How do I install RunsOn?

Follow this three-step process to install RunsOn:

Connect to your AWS account:

Use your AWS credentials to log in to the AWS console for the account where you would like to set up RunsOn.

Create the CloudFormation stack and GitHub app for RunsOn by following the official installation guide.

The installation guide has a link at the top to obtain the license key.

Once you have your key, proceed with the installation guide by selecting the AWS region you would like to use, creating the CloudFormation stack, and installing the GitHub app.

The installation process takes about 10 minutes.

At the end of the installation, follow the link to the deployed App Runner service endpoint, and you should see a page indicating that your installation is successful.

At this point you can start using RunsOn to spawn runners for your GitHub Actions workflows.

How do I execute GitHub Actions workflows?

After installing RunsOn, you can execute jobs on Arm-based runners by modifying your GitHub Actions workflow files.

If you have existing GitHub Actions workflow files, you can simply change the runs-on setting.

For example, if you have a workflow file with:

  runs-on: ubuntu-22.04

You can change the runs-on value as shown below to invoke a new runner in your AWS account.

  runs-on:
    - runs-on
    - runner=1cpu-linux-arm64
    - run-id=${{ github.run_id }}

The runner is now a Graviton-based EC2 instance with 1 vCPU running Ubuntu 22.04.

After about 30 seconds, you will see the job running on an Arm-based runner from your AWS account. The EC2 instance will be created, used, and terminated so you only pay for the time the workflow was running.

How can I specify other EC2 instance types?

You can also select other instance types, such as Graviton3 or Graviton4, by using the family parameter:

jobs:
  build:
    runs-on:
      - runs-on
      - runner=2cpu-linux-arm64
      - family=r8g # Graviton4
      - run-id=${{ github.run_id }}

You can learn more about the supported Linux runners in the official documentation.

If you would like to further customize the CPU count, RAM, disk sizes, and more, you can review the job labels.

Can you show me a complete GitHub Actions example using RunsOn?

If you don't have existing workflow files or want to try RunsOn by creating a new repository, you can run the commands below at a shell prompt. You will need Git (git) and the GitHub CLI (gh) installed. Refer to the GitHub CLI installation instructions if you don't have the gh command installed.

Create a new directory for the repository:

mkdir actions-test ; cd actions-test
git init
mkdir -p .github/workflows

Use a text editor to save the workflow file below as a file named test.yml in the .github/workflows/ directory:

name: test

on: 
  push:
  workflow_dispatch:

jobs:  
  build:    
    runs-on:      
      - runs-on      
      - runner=1cpu-linux-arm64      
      - run-id=${{ github.run_id }}    
    steps:      
      - run: echo "Hello from your Arm runner!"

Add the workflow file to the repository, and commit the changes:

git add .github/workflows/test.yml
git commit -m "initial commit for actions test"

Authorize GitHub so you can access your account from the command line:

gh auth login

Use a browser or authentication token to authorize your GitHub account.

Create the repository:

gh repo create actions-test --private --source=. --remote=origin

Save the project to GitHub:

git push -u origin master

The git push command will trigger the GitHub Action to run.

You can use a browser to view the Actions tab for the repository and see the job.

You can also see the result from the command line:

gh run list

Look at the output and find the ID. The output will be similar to:

STATUS  TITLE                            WORKFLOW  BRANCH  EVENT  ID           ELAPSED  AGE                
✓       initial commit for actions test  test      master  push   10777854144  43s      about 6 minutes ago

Print the log for the run. Substitute your job ID for the example ID shown below.

gh run view 10777854144 --log

You will see numerous details about the run, including architecture, instance name, region, instance type, and the name of the AMI (disk image).

You will also see that the instance is a spot instance (for lowest price).

build   Set up job  2024-09-09T17:05:20.0155475Z Current runner version: '2.319.1'
build   Set up job  2024-09-09T17:05:20.0163810Z Runner name: 'runs-on--i-03421942a716b3f2a--vPaXOcNxGv'
build   Set up job  2024-09-09T17:05:20.0164922Z Runner group name: 'Default'
build   Set up job  2024-09-09T17:05:20.0165868Z Machine name: 'ip-10-1-44-45'
build   Set up job  2024-09-09T17:05:20.0187255Z ##[group]Runner Instance
build   Set up job  2024-09-09T17:05:20.0188268Z |       INFO        |                      VALUE                      |
build   Set up job  2024-09-09T17:05:20.0189375Z |-------------------|-------------------------------------------------|
build   Set up job  2024-09-09T17:05:20.0190247Z | SSH               | ssh runner@XX.XX.XXX.XX                         |
build   Set up job  2024-09-09T17:05:20.0191195Z | DefaultAdmins     | []                                              |
build   Set up job  2024-09-09T17:05:20.0194359Z | Region            | us-west-2                                       |
build   Set up job  2024-09-09T17:05:20.0195723Z | AvailabilityZone  | us-west-2c                                      |
build   Set up job  2024-09-09T17:05:20.0196761Z | Version           | v2.5.0                                          |
build   Set up job  2024-09-09T17:05:20.0197751Z | Runner            | runs-on--i-03421942a716b3f2a--vPaXOcNxGv        |
build   Set up job  2024-09-09T17:05:20.0198675Z | InstanceId        | i-03421942a716b3f2a                             |
build   Set up job  2024-09-09T17:05:20.0199804Z | InstanceType      | m7g.medium                                      |
build   Set up job  2024-09-09T17:05:20.0200853Z | InstanceLifecycle | spot                                            |
build   Set up job  2024-09-09T17:05:20.0201845Z | InstanceRAM       | 3810.47 MiB                                     |
build   Set up job  2024-09-09T17:05:20.0202929Z | InstanceCPU       | 1 cores                                         |
build   Set up job  2024-09-09T17:05:20.0203988Z | InstanceDisk1     | /=/dev/nvme0n1p1                                |
build   Set up job  2024-09-09T17:05:20.0204948Z |                   | Free=31.16GiB Used=7.41GiB                      |
build   Set up job  2024-09-09T17:05:20.0205963Z | ImageId           | ami-0657d9a6ae629cc71                           |
build   Set up job  2024-09-09T17:05:20.0207032Z | ImageName         | runs-on-v2.2-ubuntu22-full-arm64-20240907064532 |
build   Set up job  2024-09-09T17:05:20.0208066Z | Platform          | linux                                           |
build   Set up job  2024-09-09T17:05:20.0209048Z | Architecture      | arm64                                           |
build   Set up job  2024-09-09T17:05:20.0210029Z | Has preinstall    | false                                           |
build   Set up job  2024-09-09T17:05:20.0211070Z | PrivateIp         | 10.1.44.45                                      |
build   Set up job  2024-09-09T17:05:20.0212487Z | Debug             | false                                           |
build   Set up job  2024-09-09T17:05:20.0213565Z | BucketCacheName   | runs-on-s3bucketcache-wdz50kvdwgnk              |
build   Set up job  2024-09-09T17:05:20.0214516Z ##[endgroup]
build   Set up job  2024-09-09T17:05:20.0215051Z ##[group]Timings
build   Set up job  2024-09-09T17:05:20.0215788Z |         TIME         |         STEP         |  DIFF   | TOTAL  |
build   Set up job  2024-09-09T17:05:20.0216832Z |----------------------|----------------------|---------|--------|
build   Set up job  2024-09-09T17:05:20.0217838Z | 2024-09-09T17:04:45Z | workflow-job-created | 0ms     | 0.0s   |
build   Set up job  2024-09-09T17:05:20.0218934Z | 2024-09-09T17:04:48Z | webhook-received     | 3400ms  | 3.40s  |
build   Set up job  2024-09-09T17:05:20.0219949Z | 2024-09-09T17:04:48Z | instance-launched    | 26ms    | 3.43s  |
build   Set up job  2024-09-09T17:05:20.0221067Z | 2024-09-09T17:04:50Z | instance-pending     | 1572ms  | 5.00s  |
build   Set up job  2024-09-09T17:05:20.0222055Z | 2024-09-09T17:05:08Z | agent-booting        | 18683ms | 23.68s |
build   Set up job  2024-09-09T17:05:20.0223051Z | 2024-09-09T17:05:08Z | agent-metadata       | 21ms    | 23.70s |
build   Set up job  2024-09-09T17:05:20.0224084Z | 2024-09-09T17:05:08Z | agent-userdata       | 215ms   | 23.92s |
build   Set up job  2024-09-09T17:05:20.0225112Z | 2024-09-09T17:05:08Z | runner-env           | 37ms    | 23.96s |
build   Set up job  2024-09-09T17:05:20.0226129Z | 2024-09-09T17:05:08Z | runner-setup-hooks   | 0ms     | 23.96s |
build   Set up job  2024-09-09T17:05:20.0227166Z | 2024-09-09T17:05:10Z | runner-disk-setup    | 1091ms  | 25.05s |
build   Set up job  2024-09-09T17:05:20.0228160Z | 2024-09-09T17:05:10Z | runner-setup-agent   | 48ms    | 25.10s |
build   Set up job  2024-09-09T17:05:20.0229734Z | 2024-09-09T17:05:10Z | runner-chown-user    | 0ms     | 25.10s |
build   Set up job  2024-09-09T17:05:20.0230634Z ##[endgroup]
build   Set up job  2024-09-09T17:05:20.0248725Z Testing runner upgrade compatibility
build   Set up job  2024-09-09T17:05:20.6787659Z ##[group]GITHUB_TOKEN Permissions
build   Set up job  2024-09-09T17:05:20.6789958Z Contents: read
build   Set up job  2024-09-09T17:05:20.6790702Z Metadata: read
build   Set up job  2024-09-09T17:05:20.6791251Z Packages: read
build   Set up job  2024-09-09T17:05:20.6791826Z ##[endgroup]
build   Set up job  2024-09-09T17:05:20.6796044Z Secret source: Actions
build   Set up job  2024-09-09T17:05:20.6796849Z Prepare workflow directory
build   Set up job  2024-09-09T17:05:20.7586035Z Prepare all required actions
build   Set up job  2024-09-09T17:05:20.7901878Z Complete job name: build
build   Set up runner   2024-09-09T17:05:20.9495781Z A job started hook has been configured by the self-hosted runner administrator
build   Set up runner   2024-09-09T17:05:21.0909000Z ##[group]Run '/opt/runs-on/pre.sh'
build   Set up runner   2024-09-09T17:05:21.0944129Z shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
build   Set up runner   2024-09-09T17:05:21.0944878Z ##[endgroup]
build   Run echo "Hello from your Arm runner!"  2024-09-09T17:05:21.1884436Z ##[group]Run echo "Hello from your Arm runner!"
build   Run echo "Hello from your Arm runner!"  2024-09-09T17:05:21.1885273Z echo "Hello from your Arm runner!"
build   Run echo "Hello from your Arm runner!"  2024-09-09T17:05:21.1914580Z shell: /usr/bin/bash -e {0}
build   Run echo "Hello from your Arm runner!"  2024-09-09T17:05:21.1915072Z env:
build   Run echo "Hello from your Arm runner!"  2024-09-09T17:05:21.1915428Z   RUNS_ON_AGENT_ARCH: arm64
build   Run echo "Hello from your Arm runner!"  2024-09-09T17:05:21.1916056Z   RUNS_ON_RUNNER_NAME: runs-on--i-03421942a716b3f2a--vPaXOcNxGv
build   Run echo "Hello from your Arm runner!"  2024-09-09T17:05:21.1916751Z   RUNS_ON_AGENT_USER: runner
build   Run echo "Hello from your Arm runner!"  2024-09-09T17:05:21.1917378Z   RUNS_ON_S3_BUCKET_CACHE: runs-on-s3bucketcache-wdz50kvdwgnk
build   Run echo "Hello from your Arm runner!"  2024-09-09T17:05:21.1918075Z   RUNS_ON_AWS_REGION: us-west-2
build   Run echo "Hello from your Arm runner!"  2024-09-09T17:05:21.1918665Z   ACTIONS_RUNNER_HOOK_JOB_STARTED: /opt/runs-on/pre.sh
build   Run echo "Hello from your Arm runner!"  2024-09-09T17:05:21.1919277Z ##[endgroup]
build   Run echo "Hello from your Arm runner!"  2024-09-09T17:05:21.2054907Z Hello from your Arm runner!
build   Complete job    2024-09-09T17:05:21.2297627Z Cleaning up orphan processes

You are now able to run GitHub Actions workflows on Graviton-based EC2 instances in your AWS account.

You will get regular e-mail from RunsOn showing your usage and cost. It costs a few cents per day for the App Runner service, plus the cost of the EC2 instances used to run workflows.

Follow the Uninstall Guide if you don't want to continue using RunsOn.

Utilizing managed, self-hosted Arm runners is a great solution if you need specific hardware such as the Graviton3 or Graviton4 processors.

Check out Arm Learning Paths for more content on AWS Graviton processors and the Arm architecture.

Investigate performance with Process Watch on AWS Graviton processors

Jason Andrews — Mon, 19 Aug 2024 20:29:12 +0000

Process Watch displays the instruction mix of the processes running on your Linux system. It recently added support for the Arm architecture, and works well on AWS Graviton processors. It can be used to quickly identify application usage of floating point, NEON, SVE, and SVE2 vector instructions.

After analyzing a running system or application with Process Watch you may be able to increase performance by recompiling applications, updating libraries, or generally finding ways to improve performance using vector instructions.

Read on to find out how to install and use Process Watch.

What software is required to build Process Watch?

The Process Watch source code is available on GitHub.

You will need various tools to build Process Watch from source:

CMake
Clang
LLVM
libelf

The instructions below are for an AWS Graviton-based EC2 instance running Ubuntu 24.04. You can modify them as needed for your Linux distribution.

To install the required tools run:

sudo apt-get update
sudo apt-get install libelf-dev cmake clang llvm llvm-dev python-is-python3 -y

Where is the Process Watch source code?

Use git to clone the Process Watch repository:

git clone --recursive https://github.com/intel/processwatch.git

Make sure to include the --recursive option to clone all submodules.

If you are curious, the submodules are:

Change to the repository directory:

cd processwatch

What is the best way to build Process Watch?

To build Process Watch, run the build script included in the repository:

./build.sh -b

You will see the following output:

Compiling dependencies...
  No system bpftool found! Compiling libbpf and bpftool...
  Compiling capstone...
Building the 'insn' BPF program:
  Gathering BTF information for this kernel...
  Compiling the BPF program...
  Stripping the object file...
  Generating the BPF skeleton header...
Linking the main Process Watch binary...

You now have the processwatch binary in the top-level directory of the repository.

For convenience, copy it to a common place included in your search path:

sudo cp ./processwatch /usr/local/bin

Do I need to run Process Watch as root?

You can run Process Watch as a non-root user, but it requires the modifications shown below, which decreases system security.

To enable non-root users to run Process Watch, you need to run the 3 commands below. If you want to run Process Watch with sudo you can skip these 3 commands and go to the next section.

sudo setcap CAP_PERFMON,CAP_BPF=+ep /usr/local/bin/processwatch
sudo sysctl -w kernel.perf_event_paranoid=-1
sudo sysctl kernel.unprivileged_bpf_disabled=0

How do I run Process Watch?

Process Watch accepts a number of command-line arguments. You can view these by running:

sudo processwatch -h

The output is:

usage: processwatch [options]

options:
  -h          Displays this help message.
  -v          Displays the version.
  -i <int>    Prints results every <int> seconds.
  -n <num>    Prints results for <num> intervals.
  -c          Prints all results in CSV format to stdout.
  -p <pid>    Only profiles <pid>.
  -m          Displays instruction mnemonics, instead of categories.
  -s <samp>   Profiles instructions with a sampling period of <samp>.
  -f <filter> Can be used multiple times. Defines filters for columns. Defaults to 'FPARMv8', 'NEON', 'SVE' and 'SVE2'.
  -l          Prints all available categories, or mnemonics if -m is specified.
  -d          Prints only debug information.

Without any options Process Watch:

Prints results every two seconds
Prints results until it is killed (using Ctrl+C)
Prints all results in a table format on stdout
Profiles all running processes
Displays counts for the default filters, which are 'FPARMv8', 'NEON', 'SVE', and 'SVE2'
Sets the sample period to every 10000 events

What does the Process Watch output look like?

You can run Process Watch with no arguments:

sudo ./processwatch

The output is similar to:

PID      NAME             FPARMv8  NEON     SVE      SVE2     %TOTAL   TOTAL
ALL      ALL              0.00     0.29     0.00     0.00     100.00   346
17400    processwatch     0.00     0.36     0.00     0.00     80.64    279
254      systemd-journal  0.00     0.00     0.00     0.00     13.01    45
542      irqbalance       0.00     0.00     0.00     0.00     2.60     09
544      rs:main Q:Reg    0.00     0.00     0.00     0.00     2.02     07
560      snapd            0.00     0.00     0.00     0.00     1.16     04
296      multipathd       0.00     0.00     0.00     0.00     0.58     02

PID      NAME             FPARMv8  NEON     SVE      SVE2     %TOTAL   TOTAL
ALL      ALL              3.57     12.86    0.00     0.00     100.00   140
17400    processwatch     3.73     13.43    0.00     0.00     95.71    134
4939     sshd             0.00     0.00     0.00     0.00     2.86     04
296      multipathd       0.00     0.00     0.00     0.00     0.71     01
560      snapd            0.00     0.00     0.00     0.00     0.71     01

PID      NAME             FPARMv8  NEON     SVE      SVE2     %TOTAL   TOTAL
ALL      ALL              1.18     5.12     0.00     0.00     100.00   254
17400    processwatch     1.19     5.16     0.00     0.00     99.21    252
6651     packagekitd      0.00     0.00     0.00     0.00     0.39     01
4939     sshd             0.00     0.00     0.00     0.00     0.39     01

New output comes every two seconds, and the next samples are appended to the bottom of the output.

Use Ctrl+C to end processwatch.

How can I use Process Watch to identify applications which could run faster?

To see an example of how Process Watch can be used, use a text editor to save the Python code below into a file named zip.py.

import gzip

size = 16384

for _ in range(3):
    with open('largefile', 'rb') as f_in:
        with gzip.open('largefile.gz', 'wb') as f_out:
            while (data := f_in.read(size)):
                f_out.write(data)

f_out.close()
print("Zip complete")

The Python code reads a file named largefile and writes a compressed version as largefile.gz.

To create the input file, use the dd command:

dd if=/dev/zero of=largefile count=1M bs=1024

Next, use a text editor to save the script below in a file named run1.sh.

#!/bin/bash

python ./zip.py &
pid=$!
sudo processwatch -p $pid -s 1 -i 2 -f HasCRC -f HasNEON &
pid2=$!
sleep 30
kill $pid2

Look at the script and see that it starts the Python code to compress largefile and then attaches processwatch to monitor for CRC and NEON instructions. The sample rate is every 1 second and the output is printed every 2 seconds.

File compression is a task that runs best when CRC instructions are used. No CRC instructions indicates an opening for performance improvement.

Run the script using:

bash ./run1.sh

The Process Watch output will start to print on stdout.

The output is similar to:

PID      NAME             CRC      NEON     %TOTAL   TOTAL   
ALL      ALL              0.00     1.63     100.00   25466   
1226     python           0.00     1.63     100.00   25466  

PID      NAME             CRC      NEON     %TOTAL   TOTAL   
ALL      ALL              0.00     1.96     100.00   23224   
1226     python           0.00     1.96     100.00   23224

Notice that no CRC instructions are shown. This is because the version of zlib supplied by the Linux distribution is not compiled with CRC instructions.

You can confirm this by running objdump to disassemble the library and look for crc32 instructions.

objdump -d /usr/lib/aarch64-linux-gnu/libz.so.1 | awk -F" " '{print $3}' | grep crc32 | wc -l

If the result is 0 then there are no crc32 instructions used in the library.

Is there a way to use CRC instructions for file compression?

If there are no crc32 instructions in zlib then you can use zlib-cloudflare to increase application performance.

To build and install zlib-cloudflare download and build using:

git clone https://github.com/cloudflare/zlib.git
cd zlib && ./configure
make && sudo make install
cd ..

With the new library installed, use a text editor to save a new bash script with the code below to the file run2.sh:

#!/bin/bash

LD_PRELOAD=/usr/local/lib/libz.so python ./zip.py &
pid=$!
sudo processwatch -p $pid -s 1 -i 2 -f HasCRC -f HasNEON &
pid2=$!
sleep 10
kill $pid2

Notice the new libz.so is used and the CRC and NEON instructions are again printed every 2 seconds.

Run the new script using:

bash ./run2.sh

This time the CRC instructions are used, and the performance is significantly faster.

The output is similar to:

PID      NAME             CRC      NEON     %TOTAL   TOTAL   
ALL      ALL              17.40    1.80     100.00   25246   
1251     python           17.40    1.80     100.00   25246   

PID      NAME             CRC      NEON     %TOTAL   TOTAL   
ALL      ALL              17.33    2.54     100.00   23556   
1251     python           17.33    2.54     100.00   23556

What else can I do with Process Watch?

Besides CRC instructions, you can use Process Watch to look for NEON, SVE, and SVE2 instructions. These are all vector extensions in Arm processors used to increase application performance.

To see examples of NEON and SVE refer to the Using Process watch Arm Learning Path.

Install Aperf for performance analysis on AWS Graviton processors

Jason Andrews — Fri, 05 Jan 2024 17:16:33 +0000

APerf (AWS Perf) is an open source command line performance analysis tool which saves time by collecting information which is normally collected by multiple tools such as perf, sysstat, and sysctl.

APerf was recently created by AWS to help with Linux performance analysis.

In addition to the CLI, APerf includes an HTML view to visualize the collected data.

Before you begin

APerf works on Linux and is available as a single binary.

APerf works best if perf is installed. Refer to the Perf for Linux on Arm install guide for instructions.

This article provides a quick solution to install APerf on AWS Graviton processors.

Confirm you are using Graviton:

uname -m

The output should be:

aarch64

Download and install APerf

The easiest way to install APerf is to download a release from GitHub, extract it, and setup your PATH environment variable or copy the executable to a directory already in your search path.

Visit the releases page to see a list of available releases.

You can also download a release from the command line:

wget https://github.com/aws/aperf/releases/download/v0.1.9-alpha/aperf-v0.1.9-alpha-aarch64.tar.gz

Extract the release:

tar xvfz aperf-v0.1.9-alpha-aarch64.tar.gz

Add the path to aperf in your .bashrc file.

echo 'export PATH="$PATH:$HOME/aperf-v0.1.9-alpha-aarch64"' >> ~/.bashrc
source ~/.bashrc

Alternatively, you can copy the aperf executable to a directory already in your search path.

sudo cp aperf-v0.1.9-alpha-aarch64/aperf /usr/local/bin

Confirm aperf is installed by printing the version:

aperf --version

The output should print the version:

aperf 0.1.0 (0c4f58c)

Verify APerf is working

Create and view a report

To confirm APerf is working, start it for 10 seconds and take a sample every 1 second.

aperf record -i 1 -p 10 -r run1 --profile

After 10 seconds aperf completes and you see a directory named run1 and a tar file named run1.tar.gz.

Next, generate a report from the recorded data:

aperf report -r run1 -n report1

The name of the report is report1 and you will see a report1 directory and a tar file named report1.tar.gz.

The tar files are useful if you want to copy them to another machine.

Using a web browser, open the file index.html in the report1/ directory. To open the file use Ctrl+O for Linux and Windows and use ⌘+O for macOS.

The report is now visible in the browser.

There are a number of tabs on the left side showing the collected data.

You can browse the data and see what has been collected.

The Kernel Config and Sysctl Data tabs are blank unless you click No.

Create and view a report containing 2 runs

To demonstrate comparing 2 runs, create a second run with aperf record:

aperf record -i 1 -p 10 -r run2 --profile

After 10 seconds aperf completes and you see a directory named run2 and a tar file named run2.tar.gz.

Generate a report with both the first and second runs included:

aperf report -r run1 -r run2 -n compare

The name of the report is compare and you will see a compare directory and a tar file named compare.tar.gz.

Open the index.html file in the compare/ directory to see the 2 runs side by side.

A screenshot is shown below:

Use an HTTP server

If you are doing performance analysis on an EC2 instance without a remote desktop, you can view the APerf reports from your local browser by running a simple web server on the remote machine.

In the directory with the report data and the index.html file run a simple web server:

python -m http.server 3000

Make sure port 3000 is open on the remote system.

You can open the port in your security group or use SSH to forward port 3000.

To use SSH (substitute your SSH key name and IP address):

ssh -i your-key.pem -L 3000:localhost:3000 ubuntu@your-ec2-ip

If you use SSH port forwarding, open your browser to http://localhost:3000

If you use the security group, enter the IP address of the EC2 instance followed by :3000 in your browser address bar.

You will see the same APerf report, and avoid the need to copy files to your local machine from the remote system for viewing.

You are ready to use APerf for performance analysis on AWS Graviton processors.

Visit https://learn.arm.com for more Graviton related content.

Use AWS Graviton processors on AWS Fargate with Copilot

Jason Andrews — Fri, 17 Nov 2023 23:01:18 +0000

AWS Copilot CLI is an open source command line interface for running containers on AWS App Runner, Amazon Elastic Container Service (ECS), and AWS Fargate.

You can use Copilot to run containers on Fargate’s serverless compute with Graviton2 processors and benefit from improved price performance.

Graviton is not the default for Copilot, but read on to find out how to change the architecture to Arm.

Before you begin

You will need Docker and Copilot on your local computer to follow the instructions below.

Your local computer can be Linux or macOS.

There are plenty of places to find Docker installation instructions. One option is the Docker install guide.

You will also need an AWS account.

To create an account, go to https://aws.amazon.com and click on Create an AWS Account in the top right corner. Follow the instructions to register. See the Creating an AWS account documentation for full instructions.

Make sure to configure your access key ID and secret access key, which are used to sign programmatic requests that you make to AWS. Refer to AWS Credentials for a quick summary of how to run aws configure. The install guide also covers how to install the AWS CLI. Make a note of the AWS region you set with aws configure so you can see the resources created by Copilot in the AWS console.

If you are using Docker on Linux you will need to install QEMU to build container images for both the arm64 and the amd64 architectures.

sudo apt-get install qemu-user-static

Docker Desktop for macOS includes the ability to build for multiple architectures, so you don't need to do anything extra.

To install Copilot on Arm Linux:

sudo curl -Lo /usr/local/bin/copilot https://github.com/aws/copilot-cli/releases/latest/download/copilot-linux-arm64 \
   && sudo chmod +x /usr/local/bin/copilot \
   && copilot --help

To install Copilot on macOS:

curl -Lo copilot https://github.com/aws/copilot-cli/releases/latest/download/copilot-darwin && chmod +x copilot && sudo mv copilot /usr/local/bin/copilot && copilot --help

Create an example application

To try Copilot on Graviton2 processors, you can use the same Go application used in Multi-architecture Kubernetes clusters on Amazon EKS.

Use an editor to create the 3 files below.

Create a file named hello.go with the contents:

// Copyright 2022 Google LLC
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
//      http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

package main

import (
    "fmt"
    "log"
    "net/http"
    "runtime"
)

func handler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "Hello from CPU PLATFORM:%s/%s",
        runtime.GOOS, runtime.GOARCH)
}

func main() {
    http.HandleFunc("/", handler)
    log.Fatal(http.ListenAndServe(":8080", nil))
}

Next, create a file named go.mod with the following two lines:

module example.com/arm
go 1.21

Create a third file named Dockerfile with the contents:

#
# Build: 1st stage
#
FROM golang:1.21-alpine as builder
ARG TARCH
WORKDIR /app
COPY go.mod .
COPY hello.go .
RUN go build -o /hello && \
    apk add --update --no-cache file && \
    file /hello

#
# Release: 2nd stage
#
FROM alpine
WORKDIR /
COPY --from=builder /hello /hello
RUN apk add --update --no-cache file
CMD [ "/hello" ]

The application listens on port 8080 and prints the architecture of the machine.

Deploy the application with Copilot

You can deploy the application with a single command:

copilot init --app go-arch               \
  --name api                             \
  --type 'Load Balanced Web Service'     \
  --dockerfile './Dockerfile'            \
  --env test                             \
  --port 8080                            \
  --deploy

The default architecture is amd64. The copilot command builds the container on your local machine for amd64, pushes it to the container registry, and creates everything needed to run on AWS Fargate.

You can also specify an existing container image using --image instead of --dockerfile. Make sure the image is a multi-architecture image supporting both arm64 and amd64.

While you are waiting for the command to complete you can look in your AWS account and see the resources created in AWS S3, CloudFormation, and ECS.

When the copilot command completes, the URL of the load balancer is printed.

Visit the URL in your browser and see the printed message.

To access the application from the command line, run curl with the URL.

For example:

curl -w '\n' http://go-arc-Publi-UvaFr7DQF5ud-988490958.us-west-2.elb.amazonaws.com

The output is:

Hello from CPU PLATFORM:linux/amd64

You can also check running status using:

copilot svc status

The output is similar to:

Found only one deployed service api in environment test
Task Summary

  Running   ██████████  1/1 desired tasks are running
  Health    ██████████  1/1 passes HTTP health checks
            ██████████  1/1 passes container health checks

Tasks

  ID        Status      Revision    Started At     Cont. Health  HTTP Health
  --        ------      --------    ----------     ------------  -----------
  7779652d  RUNNING     1           7 minutes ago  HEALTHY       HEALTHY

Migrate to Graviton

To move from amd64 to arm64 edit the file copilot/api/manifest.yml and change the platform entry from linux/x86_64 to linux/arm64.

If you don't have a platform entry, add one after the existing entries. Either way, you should have this line in your manifest.yml file:

platform: linux/arm64

You are now ready to run on Graviton2.

Save the file and redeploy the application using:

copilot svc deploy

Copilot rebuilds the container image for the arm64 architecture, pushes the image to the container registry and deploys the new image.

If you look in your AWS console and visit the task configuration in ECS, you will see the task now shows ARM64 as the architecture.

Visit the URL again using a browser or the same curl command and the message prints arm64.

Hello from CPU PLATFORM:linux/arm64

Open a shell in the container

If you need to troubleshoot a container, you can use Copilot to connect.

copilot svc exec

Answer yes to install the Session Manager plugin, and you have a shell into the running container.

Starting session with SessionId: ecs-execute-command-0f1f212e5ff00ec05
/ #

You can make changes to the container and do any needed investigation. Copilot is an easy way to connect to running containers.

Summary

You have deployed a containerized application on Fargate running AWS Graviton2 processors using Copilot. The Copilot CLI makes it much easier to create the required resources and easily make changes using the manifest.yml file.

There doesn't seem to be a way to specify arm64 on the initial copilot init command, but it would be a useful enhancement.

Clean up the AWS resources

Delete the resources created by Copilot by running:

copilot app delete

Multi-architecture Kubernetes clusters on Amazon EKS

Jason Andrews — Mon, 30 Oct 2023 21:01:12 +0000

AWS Graviton processors continue to deliver price performance for cloud workloads. Migrating Kubernetes applications can be tricky, but AWS and Docker provide tools to make the process easier.

You can experiment with multi-architecture clusters to better understand the price performance benefits, and select the best hardware for the task. Multi-architecture clusters also ease migration when some software components are not available for the Arm architecture.

Refer to the The Insider’s Guide to Building a Multi-Arch Infrastructure for more information on the benefits of multi-architecture Kubernetes clusters.

Multi-architecture Kubernetes clusters

A multi-architecture Kubernetes cluster runs workloads on multiple hardware architectures, typically arm64 and amd64 (using Docker terminology).

To learn more about multi-architecture Kubernetes you can create a cluster in Amazon EKS and gain some practical experience with arm64 and amd64 nodes. This will also help you understand multi-architecture container images.

Before you begin

You will need docker, eksctl and kubectl on your local computer to try out the steps below.

Your local computer can be Windows, Linux, or macOS. The instructions generally assume Linux.

Multipass from Canonical is a great tool for Linux virtual machines if you use macOS.

You can refer to the Kubectl install guide and the AWS EKS CLI install guide for installation details. The guides provide details for Arm Linux machines, but links to installation information about other platforms are also provided.

There are plenty of places to find Docker installation instructions. One option is the Docker install guide.

You will also need an AWS account.

Multi-architecture containers

Before you can try out a multi-architecture Kubernetes cluster, you need a multi-architecture container image.

Multi-architecture container images are the easiest way to deploy applications, and hide the underlying hardware architecture. Building multi-architecture images is slightly more complex compared to building single-architecture images.

Docker provides two ways to create multi-architecture images:

docker buildx builds both architectures at the same time
docker manifest builds each architecture separately and joins them together into a multi-architecture image

You can read more about how to create container images in the article Using Docker manifest to create multi-arch images on AWS Graviton processors

Below is a simple Go application you can use to learn about multi-architecture Kubernetes clusters.

Use your favorite text editor to create a file named hello.go with the contents below:

// Copyright 2022 Google LLC
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
//      http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

package main

import (
    "fmt"
    "log"
    "net/http"
    "os"
    "runtime"
)

func handler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "Hello from image NODE:%s, POD:%s, CPU PLATFORM:%s/%s",
        os.Getenv("NODE_NAME"), os.Getenv("POD_NAME"), runtime.GOOS, runtime.GOARCH)
}

func main() {
    http.HandleFunc("/", handler)
    log.Fatal(http.ListenAndServe(":8080", nil))
}

Next, create a file named go.mod with the following two lines:

module example.com/arm
go 1.21

Create a third file named Dockerfile with the contents:

ARG T

#
# Build: 1st stage
#
FROM golang:1.21-alpine as builder 
ARG TARCH
WORKDIR /app
COPY go.mod .
COPY hello.go .
RUN GOARCH=${TARCH} go build -o /hello && \
    apk add --update --no-cache file && \
    file /hello   

#
# Release: 2nd stage
#
FROM ${T}alpine
WORKDIR /
COPY --from=builder /hello /hello
RUN apk add --update --no-cache file
CMD [ "/hello" ]

Docker buildx

With the three text files created, you can build the container using docker buildx.

Before you start, log in to Docker Hub:

docker login

Run the commands below to build the image, and make sure to substitute your own Docker ID instead of jasonrandrews.

docker buildx create --use --name builder
docker buildx build --platform linux/amd64,linux/arm64 -t jasonrandrews/go-arch-x:1.0 --push .

When the commands are complete, you will see the new image in your Docker Hub account. Note, this is the go-arch-x repository.

Docker manifest

You can also use docker manifest to create a multi-architecture image from two single-architecture images. This is an alternative way to to build the multi-architecture image, but you can also use it to learn how to deploy a container image that only supports one architecture.

Substitute your Docker ID instead of jasonrandrews and run these commands on an amd64 machine:

# Build for amd64
docker build -t jasonrandrews/go-arch:amd64 --build-arg TARCH=amd64 --build-arg T=amd64/ .
docker push jasonrandrews/go-arch:amd64

Substitute your Docker ID instead of jasonrandrews and run these commands on an arm64 machine:

# Build for arm64
docker build -t jasonrandrews/go-arch:arm64 --build-arg TARCH=arm64 --build-arg T=arm64v8/ .
docker push jasonrandrews/go-arch:arm64

After building individual containers for each architecture, merge them into a single image by running the commands below on either architecture:

docker manifest create jasonrandrews/go-arch:1.0 \
--amend jasonrandrews/go-arch:arm64 \
--amend jasonrandrews/go-arch:amd64
docker manifest push --purge jasonrandrews/go-arch:1.0

You now have two single-architecture images in your Docker Hub account and the combined multi-architecture image in the same repository. Note, this is the go-arch repository.

In the sections below, you will learn how to deploy the images in Amazon EKS.

Create a multi-architecture Kubernetes cluster

You can use eksctl to create a cluster with multiple architectures.

First, use a text editor to create a text file cluster.yaml with the contents below:

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: cluster1
  region: us-east-1

nodeGroups:
  - name: ng-1
    instanceType: t2.micro
    desiredCapacity: 2
    volumeSize: 80
  - name: ng-2
    instanceType: t4g.small
    desiredCapacity: 2
    volumeSize: 80

The instance types above take advantage of free tier and the T4g free trial.

Run the eksctl command with the yaml file to create an EKS cluster:

eksctl create cluster -f cluster.yaml

The cluster includes two amd64 nodes and two arm64 nodes.

It takes 15-20 minutes to launch the cluster so take a break while it is created.

When the cluster is ready check the nodes by running kubectl on your local machine:

kubectl get nodes

The output shows four nodes, but doesn't print the architecture.

NAME                             STATUS   ROLES    AGE    VERSION
ip-192-168-11-18.ec2.internal    Ready    <none>   106s   v1.27.5-eks-43840fb
ip-192-168-27-254.ec2.internal   Ready    <none>   71s    v1.27.5-eks-43840fb
ip-192-168-32-244.ec2.internal   Ready    <none>   106s   v1.27.5-eks-43840fb
ip-192-168-61-31.ec2.internal    Ready    <none>   72s    v1.27.5-eks-43840fb

To get the architecture run:

kubectl get node -o jsonpath='{.items[*].status.nodeInfo.architecture}'

The output shows four nodes, two of each architecture.

arm64 amd64 amd64 arm64

The Kubernetes cluster is now ready to use, and you can deploy the Go app.

Create a service to deploy

To deploy the application create a text file named hello-service.yaml with the contents:

apiVersion: v1
kind: Service
metadata:
  name: hello-service
  labels:
    app: hello
    tier: web
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 8080
  selector:
    app: hello
    tier: web

Deploy the service by running:

kubectl apply -f hello-service.yaml

The output is:

service/hello-service created

Deploy the amd64 application

You can deploy the amd64 container first to demonstrate a single-architecture container.

Create a text file named amd64-deployment.yaml with the contents below. Make sure to use your Docker ID instead of jasonrandrews in the file. Notice that the container image is go-arch:amd64. The amd64 image will only run on amd64 nodes. The nodeSelector is used to make sure the continer is only scheduled on amd64.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: amd-deployment
  labels:
    app: hello
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hello
      tier: web
  template:
    metadata:
      labels:
        app: hello
        tier: web
    spec:
      containers:
      - name: hello
        image: jasonrandrews/go-arch:amd64
        imagePullPolicy: Always
        ports:
          - containerPort: 8080
        env:
          - name: NODE_NAME
            valueFrom:
              fieldRef:
                fieldPath: spec.nodeName
          - name: POD_NAME
            valueFrom:
              fieldRef:
                fieldPath: metadata.name
        resources:
          requests:
            cpu: 300m
      nodeSelector:
        kubernetes.io/arch: amd64

Deploy the amd64 container by running:

kubectl apply -f amd64-deployment.yaml

You can see the running deployment.

kubectl get pods

The output shows 1 pod running:

NAME                              READY   STATUS    RESTARTS   AGE
amd-deployment-7d4d44889d-vzhpd   1/1     Running   0          9s

To get the endpoint of the service run:

kubectl get services

The output prints the IP address of the load balancer.

NAME            TYPE           CLUSTER-IP       EXTERNAL-IP                                                               PORT(S)        AGE
hello-service   LoadBalancer   10.100.188.181   a5d50ef4f76f3414a9f7e6e91ada5447-1826701750.us-east-1.elb.amazonaws.com   80:30489/TCP   70s
kubernetes      ClusterIP      10.100.0.1       <none>                                                                    443/TCP        14m

To confirm the amd64 application is running use curl and substitute the endpoint of your load balancer:

curl -w '\n' http://a5d50ef4f76f3414a9f7e6e91ada5447-1826701750.us-east-1.elb.amazonaws.com

The output displays the hello message from the application and confirms the architecture is amd64.

Hello from image NODE:ip-192-168-32-244.ec2.internal, POD:amd-deployment-7d4d44889d-vzhpd, CPU PLATFORM:linux/amd64

Save the address of your load balancer (the http address) and use it for the curl commands in the following sections.

Deploy the arm64 application

Create a text file named arm64-deployment.yaml with the contents below. Again, substitute your Docker ID and notice that the nodeSelector is now arm64.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: arm-deployment
  labels:
    app: hello
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hello
      tier: web
  template:
    metadata:
      labels:
        app: hello
        tier: web
    spec:
      containers:
      - name: hello
        image: jasonrandrews/go-arch:arm64
        imagePullPolicy: Always
        ports:
          - containerPort: 8080
        env:
          - name: NODE_NAME
            valueFrom:
              fieldRef:
                fieldPath: spec.nodeName
          - name: POD_NAME
            valueFrom:
              fieldRef:
                fieldPath: metadata.name
        resources:
          requests:
            cpu: 300m
      nodeSelector:
        kubernetes.io/arch: arm64

Deploy the arm64 container by running:

kubectl apply -f arm64-deployment.yaml

You can see the running deployment.

kubectl get pods

Now, the output shows both deployments, amd64 and arm64.

NAME                              READY   STATUS    RESTARTS   AGE
amd-deployment-7d4d44889d-vzhpd   1/1     Running   0          3m1s
arm-deployment-5996f6b85d-wp8cv   1/1     Running   0          10s

Run the curl command a few times and you will see a mix of amd64 and arm64 messages printed, depending on which node services the request.

curl -w '\n' http://a5d50ef4f76f3414a9f7e6e91ada5447-1826701750.us-east-1.elb.amazonaws.com

Deploy the multi-architecture application

You can also deploy the multi-architecture image.

Create a text file named multi-arch-deployment.yaml with the contents below. Again, substitute your Docker ID. The image is the multi-architecture image created with docker buildx and 6 replicas are specified.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: multi-arch-deployment
  labels:
    app: hello
spec:
  replicas: 6
  selector:
    matchLabels:
      app: hello
      tier: web
  template:
    metadata:
      labels:
        app: hello
        tier: web
    spec:
      containers:
      - name: hello
        image: jasonrandrews/go-arch-x:1.0
        imagePullPolicy: Always
        ports:
          - containerPort: 8080
        env:
          - name: NODE_NAME
            valueFrom:
              fieldRef:
                fieldPath: spec.nodeName
          - name: POD_NAME
            valueFrom:
              fieldRef:
                fieldPath: metadata.name
        resources:
          requests:
            cpu: 300m

Deploy the multi-architecture container by running:

kubectl apply -f multi-arch-deployment.yaml

You can see the running deployment.

kubectl get pods

Now, the output shows all three deployments:

NAME                                     READY   STATUS    RESTARTS   AGE
amd-deployment-7d4d44889d-vzhpd          1/1     Running   0          4m24s
arm-deployment-5996f6b85d-wp8cv          1/1     Running   0          93s
multi-arch-deployment-547684cd44-7w6vf   1/1     Running   0          7s
multi-arch-deployment-547684cd44-chcc8   1/1     Running   0          7s
multi-arch-deployment-547684cd44-kw966   1/1     Running   0          7s
multi-arch-deployment-547684cd44-r4789   1/1     Running   0          7s
multi-arch-deployment-547684cd44-vqwc7   1/1     Running   0          7s
multi-arch-deployment-547684cd44-w4x8d   1/1     Running   0          7s

To test the appliation, run a loop of curl commands and see the output messages from the application.

for i in $(seq 1 10); do curl -w '\n' http://a5d50ef4f76f3414a9f7e6e91ada5447-1826701750.us-east-1.elb.amazonaws.com; done

The output will show a variety of amd64 and arm64 messages:

Hello from image NODE:ip-192-168-32-244.ec2.internal, POD:multi-arch-deployment-547684cd44-w4x8d, CPU PLATFORM:linux/amd64
Hello from image NODE:ip-192-168-61-31.ec2.internal, POD:multi-arch-deployment-547684cd44-r4789, CPU PLATFORM:linux/arm64
Hello from image NODE:ip-192-168-61-31.ec2.internal, POD:multi-arch-deployment-547684cd44-r4789, CPU PLATFORM:linux/arm64
Hello from image NODE:ip-192-168-27-254.ec2.internal, POD:multi-arch-deployment-547684cd44-kw966, CPU PLATFORM:linux/arm64
Hello from image NODE:ip-192-168-61-31.ec2.internal, POD:multi-arch-deployment-547684cd44-chcc8, CPU PLATFORM:linux/arm64
Hello from image NODE:ip-192-168-27-254.ec2.internal, POD:arm-deployment-5996f6b85d-wp8cv, CPU PLATFORM:linux/arm64
Hello from image NODE:ip-192-168-32-244.ec2.internal, POD:multi-arch-deployment-547684cd44-w4x8d, CPU PLATFORM:linux/amd64
Hello from image NODE:ip-192-168-32-244.ec2.internal, POD:multi-arch-deployment-547684cd44-w4x8d, CPU PLATFORM:linux/amd64
Hello from image NODE:ip-192-168-32-244.ec2.internal, POD:multi-arch-deployment-547684cd44-w4x8d, CPU PLATFORM:linux/amd64
Hello from image NODE:ip-192-168-61-31.ec2.internal, POD:multi-arch-deployment-547684cd44-r4789, CPU PLATFORM:linux/arm64

You have now deployed single-architecture images for amd64 and arm64 as well as six copies of a multi-architecture image.

You can use the same techniques to incrementally migrate applications from amd64 to arm64 and invesigate the price performance provided by AWS Graviton processors.

Delete the clusters

When you are done, make sure to delete all AWS resources.

You can clean up with a single eckctl command.

eksctl delete cluster -n cluster1

Arm Learning Paths

Jason Andrews — Tue, 27 Jun 2023 13:29:20 +0000

One of the reasons I joined the AWS Community Builders program is to share articles about AWS Graviton processors in the AWS Community Builders DEV organization.

After joining, I got started right away, and I try to share a handful of original articles every year. I feel like the material is well received, and I have provided a meaningful contribution for those learning about Graviton processors and the Arm architecture.

I am now entering my 4th year in the Community Builders program.

Last year, I noticed that my past articles might need some updating as things have changed since 2020. Software versions change, Windows 10 is now Windows 11, and new Graviton-based EC2 instance types are available.

I also learned that blogging is not exactly the same thing as publishing hands-on how-to content for developers, especially in the updating area. After some research and development into what else would be useful for software developers, I’m excited to share Arm Learning Paths.

Learning Paths provide long-form, written how-to content for software developers.

Background

As a long-time blogger, I have written many articles linking news and events with new tools, hardware, and software as a way to learn.

Over time, the news fades, but the technical content is still important. Readers wonder if the material is still correct or if they should search for something else. Some of my past articles are currently in this state.

I knew I wanted to share more written how-to content, but didn't always feel like writing more blogs was the answer.

Documentation is another way to deliver written how-to content, but documentation is tied to a product such as a tool, software library, or API. It doesn't always provide the context and big picture about how things work. Sometimes documentation provides too much information.

About a year ago, my small team started investigating long-form, written how-to content at Arm. We found useful content in many places:

Guides on developer.arm.com
Blogs on community.arm.com
Articles on general social media sites such as LinkedIn
Community specific sites such as blog.tensorflow.org, hackster.io and dev.to

I have written and read articles in all these places. They are all fine, but none of them felt like what I wanted to do.

To find out more, we conducted interviews and did market research into what developer surveys tell us.

From the research, we established a list of things we wanted developers to be able to do:

Explore platforms, tools, and software available for the Arm architecture
Learn from hands-on, how-to content grouped by target hardware platforms
Find out what’s possible and explore what can be done with Arm
Understand the context and alternatives when there are multiple ways to do a task

Two key points stood out.

We needed to provide an easy environment for creators to publish to a location with high traffic.

Learning Paths must be a community project for everyone to participate.

Building Learning Paths

Last year, we started to prototype the Learning Path website with the following characteristics:

Fast, static website on an arm.com URL
Easy publishing flow using markdown files
Community contributions via GitHub
Appropriate governance
Timeless, quality content
Free from direct marketing
Always up to date
Automated testing and maintenance
Open-source license which complies with Arm open-source requirements
Analytics and dashboard
No content behind a login
Meets performance, security, and accessibility requirements

We have now completed the Learning Path website with the listed characteristics and are ready to share it with you.

Over the approximately one year of development, we have had:

15+ contributors
Over 2000 git commits
90+ Learning Paths
45+ Install Guides

The content is now available on learn.arm.com for you to review and share. All content is stored in a GitHub project and uses Hugo to generate a static website. The website automatically updates when new content is reviewed and accepted.

Give it a try

There are a number of Learning Paths covering AWS services in the Servers and Cloud Computing category.

Please share learn.arm.com in places you connect with software developers and tool providers.

You can create a Learning Path or submit improvements via GitHub. Click the Create button on the front page to find out more about how to create a Learning Path.

Feel free to send me a message for a 10-minute quick start.

Time will tell how well the concept is received, but I hope Learning Paths become another useful place for creators to publish and readers to learn.

I will continue to write here in the AWS Community Builders DEV organization also. Congratulations to everyone for creating so many useful articles.

Improve data compression performance on AWS Graviton processors

Jason Andrews — Thu, 15 Sep 2022 02:06:00 +0000

Applications in many programming languages perform data compression. They commonly rely on zlib for easy handling of gzip files. This article explains how to improve performance of applications using zlib on AWS Graviton processors.

Most Linux distributions use zlib without any optimizations. For the Arm architecture, this means that CRC (cyclic redundancy check) instructions are not utilized for best performance. Installing and using a zlib which has been optimized may provide performance improvement for applications doing data compression. Let's see how to do it with an example Python application.

Cloudflare zlib is one version which has optimizations included. There are other zlib versions which have been optimized. The process to use them should be similar.

This can be done on any Graviton-based instance. I did it with Ubuntu 22.04.

Confirm crc32 is included in the processor flags

All AWS Graviton processors and most Armv8.0-A and above processors have support for CRC instructions.

To check if a Linux system has support, use the lscpu command and look for crc32 in the listed flags.

lscpu | grep crc32

If the machine is confirmed to include crc32 it may benefit from zlib-cloudflare.

Check if the default zlib includes crc32 instructions

Some Linux systems may already make use of crc32 in the default library. If the default zlib is already optimized, then using zlib-cloudflare may not have any impact on performance.

Ubuntu and Debian Linux distributions put zlib in /usr/lib/aarch64-linux-gnu

Other software tools are needed to build zlib, so install them now.

sudo apt install -y build-essential

To check if there are any CRC instructions in a library, use objdump to disassemble and look for crc32 instructions.

objdump -d /usr/lib/aarch64-linux-gnu/libz.so.1 | awk -F" " '{print $3}' | grep crc32 | wc -l

If the result is 0 then there are no crc32 instructions used in the library.

Install Cloudflare zlib

If there are no crc32 instructions in zlib then zlib-cloudflare may help application performance.

To build and install zlib-cloudflare navigate to an empty directory and use these commands.

mkdir tmp ; pushd tmp
git clone https://github.com/cloudflare/zlib.git
cd zlib && ./configure 
make && sudo make install
popd
rm -rf tmp

If successful, zlib-cloudflare is installed in /usr/local/lib

Confirm the new zlib has crc32 instructions. The objdump command should return a non-zero number now.

objdump -d /usr/local/lib/libz.so  | awk -F" " '{print $3}' | grep crc32 | wc -l

To install zlib somewhere else, use the prefix argument to select another location.

./configure --prefix=$HOME/zlib

This results in zlib being installed in $HOME/zlib instead.

Configuring zlib

Below is a simple C program to demonstrate zlib usage.

#include <stdio.h>
#include <stdlib.h>
#include "zlib.h"

int main()
{

    gzFile myfile;

    printf("%s\n", zlibVersion());

    myfile = gzopen("testfile.gz", "wb");

    gzprintf(myfile,"Hello gzipped file!\n");

    gzclose(myfile);

    exit(0);
}

Save the text above as a file named test.c and compile the example.

gcc test.c -o test -lz

Run the program and see the version.

./test

The printed version will be a number such as:

1.2.11

Use ldd to see the location of the shared library.

ldd ./test

The output shows the shared libraries used by test.

linux-vdso.so.1 (0x0000ffff91026000)
libz.so.1 => /lib/aarch64-linux-gnu/libz.so.1 (0x0000ffff90fa0000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffff90df0000)
/lib/ld-linux-aarch64.so.1 (0x0000ffff90fed000)

Set LD_PRELOAD to use zlib-cloudflare

To run test with zlib-cloudflare instead of the default.

LD_PRELOAD=/usr/local/lib/libz.so ./test

The LD_PRELOAD variable informs the linker to use these libraries before the default libraries.

The version of zlib-cloudflare will be printed. It may be older than the default, but we are interested in crc32 and not using the latest.

Next, let's see how to use zlib-cloudflare in an application doing data compression. We can use a Python example and measure the performance difference with zlib-cloudflare.

Copy and save the file below as zip.py

import gzip

size = 16384

with open('largefile', 'rb') as f_in:
    with gzip.open('largefile.gz', 'wb') as f_out:
        while (data := f_in.read(size)):
            f_out.write(data)

f_out.close()

For Ubuntu 22.04, configure python to be python3.

sudo apt install python-is-python3 -y

Create a large file to compress

The above Python code will read a file named largefile and write a compressed version as largefile.gz

To create the input file, use the dd command.

dd if=/dev/zero of=largefile count=1M bs=1024

Run the example using the default zlib

Run with the default zlib and time the execution.

time python ./zip.py

Make a note of the runtime.

Run the example again with zlib-cloudflare

This time, use LD_PRELOAD to change to zlib-cloudflare and check the performance difference.

Adjust the path to libz.so as needed.

time LD_PRELOAD=/usr/local/lib/libz.so python ./zip.py

Notice the shorter runtime when zlib-cloudflare is used.

Using a c6g.large EC2 instance, the time with the original zlib is about 7.25 seconds and with zlib-cloudflare the time is about 2.66 seconds.

Summary

If you have applications using zlib make sure to check alternative versions of the library. Cloudflare zlib is a good one, and there may be others available. Watch the AWS Graviton Getting Started for the latest information.

Using Docker manifest to create multi-arch images on AWS Graviton processors

Jason Andrews — Wed, 31 Aug 2022 17:33:48 +0000

Docker manifest is an experimental command to build docker images which support multiple architectures. Let's see how it works and compare it to docker buildx.

In 2019, docker buildx was created as a way to build multi-architecture images. At the time, developers didn't have Arm in the cloud or on their desk. Projects were interested in the Arm architecture, but as a secondary option for AWS Graviton or even Raspberry Pi. With buildx, a single build command creates a multi-architecture image. In some cases, an Arm machine is not even needed for the build.

Today, developers are using the Arm architecture on their desk and in the cloud. The trailblazing success of AWS Graviton processors has motivated developers to try out Graviton for themselves. The popularity of Mac computers with Apple silicon means many developers have the same architecture on their desk. Today, I will explain how to build multi-arch images using the docker manifest command. I have found this to be the easiest way to create multi-arch images for many projects.

Background

Docker buildx provides a build command to create images for multiple architectures. I’m primarily using arm64 and amd64. If you use other architectures, the concept can easily be extended.

The challenge with buildx is that it uses emulation, cross-compilation, or a remote builder for the target architectures which do not match the build machine. Emulation works fine for building images which primarily copy and install files, but it can suffer from functional issues or performance problems for more complex image building. Sometimes cross-compilation is easy, but sometimes it is difficult. Using a remote builder is not convenient for testing changes. Changing the remote builder setup while testing can be confusing.

Docker buildx also confuses developers who are expecting a local image to immediately run after a successful build. Because buildx targets multiple architectures, it must be saved to a repository, not local storage. This requires a push to a repository and then a pull to run. There are some other workarounds, but the use model is different from what many developers expect. Searching Stack Overflow and GitHub confirms that a missing image after successfully running buildx is a common question.

I spend the majority of my time on the Arm architecture. A shrinking number of projects require amd64 support, but when they do, I find myself shying away from buildx. Docker buildx is one way to approach the challenges of multiple architectures, but docker manifest feels easier for me.

Let's see how it works.

Docker manifest

Docker includes an experimental feature called docker manifest. Please be aware the feature is experimental and not recommended for production use.

Docker manifest provides a different way of working. It allows separate images to be built for each architecture, which can be joined into a multi-arch image when it's time to share. This enables me to build and test on any architecture and postpone using multi-arch until later. When it's time to share a multi-arch image, it can be created in seconds using docker manifest. Docker manifest also makes it easy to update one of the architectures without emulation or remote builders.

Let’s do a quick comparison between buildx and docker manifest.

Here is a small example Dockerfile.



FROM alpine AS builder
RUN apk add build-base
WORKDIR /home
COPY hello.c .
RUN gcc "-DARCH=\"`uname -a`\"" hello.c -o hello

FROM alpine
WORKDIR /home
COPY --from=builder /home/hello .
CMD ["./hello"]

The Dockerfile compiles and runs a hello world C program.



#include <stdio.h>
#include <stdlib.h>

#ifndef ARCH
#define ARCH "Undefined"
#endif

int main()
{
    printf("Hello Arm Developers, architecture from uname is %s\n", ARCH);

    switch (sizeof(void *))
    {
        case 4:
            printf("32-bit userspace\n");
            break;
        case 8:
            printf("64-bit userspace\n");
            break;
        default:
            printf("unknown userspace\n");
    }
    exit(0);
}

Copy the Dockerfile and hello.c to your computer for the steps below.

Let’s see how to use it with buildx to build a multi-architecture image.

Docker buildx

Using buildx involves setting up a builder and running the buildx command.

Below is a script showing how to use buildx. Copy the file, change the HUBU variable to your Docker Hub username, and run the script to try it.



#!/bin/bash

HUBU=hubuser
IMG=hello-world

docker buildx create --name mybuilder
docker buildx use mybuilder
docker buildx build --platform linux/amd64,linux/arm64 -t $HUBU/$IMG --push .

The script automatically pushes the multi-arch image to Docker Hub. Without the push argument, the results will not be available. It’s easy enough to pull the image and run it, but with a larger image it does take time to push to the registry and pull it back.

There are numerous tutorials about using buildx if you want to learn more.

Docker manifest

The docker manifest command is useful to combine multiple existing images into a single multi-architecture image.

To keep track of the images, I use the image tag to indicate the architecture.

To build the same Dockerfile without buildx use this command. This produces a single image, just for the architecture of the current machine.



docker build -t hello-world:$(arch) .

The image is available locally to run. On AWS Graviton, the tag will be aarch64 to differentiate it from the same command run on an x86_64 machine.

After building an image on each machine you want to support, tag the images for a Docker Hub account and push. Again, change to your Docker Hub username to try it.



docker tag hello-world:$(arch) jasonrandrews/hello-world:$(arch)
docker push jasonrandrews/hello-world:$(arch)

The image below shows both tags in Docker Hub.

The last step is to join the two tags into a single multi-architecture image.



docker manifest create jasonrandrews/hello-world:latest \
--amend jasonrandrews/hello-world:aarch64 \
--amend jasonrandrews/hello-world:x86_64

docker manifest push --purge jasonrandrews/hello-world:latest

The purge option is not needed the first time, but I found that to update one of the images and update the multi-arch image it was needed.

After the manifest push, a new multi-arch image with the latest tag is available. Pulling hello-world:latest from either architecture now works, and a user doesn't need to pay attention to the computer they are using.

Summary

The experimental docker manifest command offers a way to create multi-architecture images by joining multiple images using a manifest. Docker manifest provides additional features not covered here, and is useful to create, inspect, and modify manifest lists. As the docker manifest command matures and developers increase AWS Graviton usage, it provides another way to build docker images.

Give it a try and see how it works.