Tag: arm

Amazon EC2 的 M6g 系列正式推出了

先前提到 AWS 要在 EC2 上推出新的 ARM 架構主機 (參考「Amazon EC2 推出了新一代的 ARM 系統」這篇)，最近正式推出了：「New – EC2 M6g Instances, powered by AWS Graviton2」。

當時的定價還沒出來，現在正式開賣後可以拉出來看了。

拿 us-east-1 上 2 vCPU + 8GB RAM 這個級距的價錢出來，m5.large 是 USD$0.096/hour，m6g.large 是 USD$0.077/hour，低大約 20%，不過這是兩個不同的平台，只是抓一下感覺知道差距。

不過這個價差其實蠻有吸引力的，對於有支援 ARM 的應用程式，或是手上有 source code 的大型應用，可以測試看看效能有差多少，或是先等一下，這陣子應該就會有人初步測一些數字出來可以參考。

另外 AWS 有打算要出 C6g 與 R6g 的計畫，算是在雲上面補齊 ARM 的戰線：

We are not going to stop at general purposes M6g instances, compute optimized C6g instances and memory optimized R6g instances are coming soon, stay tuned.

目前支援的區域不算多，不過幾個老區域都先上了：

Now it’s your turn to give it a try in one the following AWS Regions : US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), Europe (Frankfurt), and Asia Pacific (Tokyo).

在 x86-64 上跑 Raspberry Pi 的 OS

看到「dockerpi」這個專案，讓你可以在 x86-64 上模擬 Raspberry Pi 環境跑 Raspbian。

然後整包是先透過 Docker 產出一個獨立環境，然後裡面跑 QEMU 模擬 ARM 的環境，接下來再跑 Raspbian：

A full ARM environment is created by using Docker to bootstrap a QEMU virtual machine. The Docker QEMU process virtualises a machine with a single core ARM11 CPU and 256MB RAM, just like the Raspberry Pi. The official Raspbian image is mounted and booted along with a modified QEMU compatible kernel.

這馬上讓人想到 Inception 啊 XDDD

Anyway，這個方法對於想玩玩的人可以省不少功夫，是個有趣的專案就是了...

Amazon EC2 推出了新一代的 ARM 系統

Amazon EC2 推出了新一代的 ARM 系統：「Coming Soon – Graviton2-Powered General Purpose, Compute-Optimized, & Memory-Optimized EC2 Instances」。

目前的 a1 系列最大到 32GB RAM，這次推出來的算是比較大台的機器，而且與 x86-64 架構相同，分化成 m/c/r 系列了：

  • General Purpose (M6g and M6gd) – 1-64 vCPUs and up to 256 GiB of memory.
  • Compute-Optimized (C6g and C6gd) – 1-64 vCPUs and up to 128 GiB of memory.
  • Memory-Optimized (R6g and R6gd) – 1-64 vCPUs and up to 512 GiB of memory.

預定是 2020 年推出：

I will have more information to share with you in 2020.

不過如果目前想要玩的話，可以找 AWS 申請 m6g 的機器先測試看看：

M6g Preview
We are now running a preview of the M6g instances for testing on non-production workloads; if you are interested, please contact us.

價錢好像也還沒出來，先放著等新消息好了...

EC2 的 ARM 也支援 bare metal 版本了...

AWS 對 ARM 平台的採用速度比想像中快，昨天發表了 bare metal 版本 a1.metal：「Now Available: Bare Metal Arm-Based EC2 Instances」。

相較於 x86 系列提供的 bare metal，ARM 這邊提供的機器不算大台，只有 16 核心與 32 GB 的記憶體，所以主要的用途應該是在於可以存取系統底層的資訊，或是因為軟體的授權不支援虛擬化而需要租用 bare metal：

  • need access to physical resources and low-level hardware features, such as performance counters, that are not always available or fully supported in virtualized environments,
  • are intended to run directly on the hardware, or licensed and supported for use in non-virtualized environments.

這次的 a1.metal 共八區可以用：

You can start using a1.metal instances today in US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Tokyo), Asia Pacific (Mumbai), and Asia Pacific (Sydney).

反過來在 ARM 上面跑 x86 模擬器...

看到「Box86 - Linux Userspace x86 Emulator with a twist, targeted at ARM Linux devices」這個專案，在 ARM 的機器上跑 x86 模擬器：

然後其實作者還弄了不少東西，像是透過 GL4ES 處理 OpenGL 的界面，其實前面做的功夫比想像中高不少...

然後從作者給的範例可以看出來主力在遊戲 XDDD

24 Core 的 ARM Server...

在「Banana Pi to Launch a 24-Core Arm Server」這邊看到 Banana Pi 打算推出 24 core 的 ARM server...

看起來還蠻不錯的：

We have 24-core Arm Cortex A53 processor with 32GB RAM (29.4GB seen by the OS) running Ubuntu 18.04.1 LTS with MATE desktop. There aren’t that many 24-core Arm Cortex A53 processors, so unless the company is using an announced processor, it has to be SocioNext SC2A11 processor also found in Linaro Developer Box.

拿來當 desktop 好像也不錯，不知道最終的定價會是多少...

EC2 推出 ARM 架構的機器...

看到 AWS 推出使用 ARM 架構的 EC2 instance 了：「New – EC2 Instances (A1) Powered by Arm-Based AWS Graviton Processors」。

在 Quick Start 頁面有 Ubuntu 18.04 (ARM) 可以選，開起來後操作跟標準的 Ubuntu 差不多... 連進去後 uname -a 可以看到是 aarch64：

ubuntu@ip-172-30-2-207:~$ uname -a
Linux ip-172-30-2-207 4.15.0-1028-aws #29+nutmeg8-Ubuntu SMP Tue Nov 20 02:59:41 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux

然後來看硬體規格，從最大台的 a1.4xlarge 來看是 16 vCPU + 32 GB RAM，定價是 $0.408/hr (這邊都拿 us-east-1 比較)。

對照 General Purpose 的 m5.4xlarge 是 16 vCPU + 60 GB RAM，定價是 $0.768/hr。如果看記憶體比較接近的 m5.2xlarge 則是 8 vCPU + 31 GB RAM，定價是 $0.384/hr。

對照 Compute Optimized 的 c5.4xlarge 是 16 vCPU + 68 GB RAM，定價是 $0.68/hr。

實際跑一些測試，包括 md5、sha256 與 aes (最後 aes 這個通常都有硬體加速)，都用 -mutli 16 跑。

ARM 的 a1.4xlarge：

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
md5            1064103.21k  2484789.44k  4436178.60k  5521370.45k  5943380.65k  5963896.15k
sha256         2059690.93k  5652827.82k 11792656.30k 16108863.15k 18086602.36k 18250851.29k
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128 cbc    1593981.48k  1723960.38k  1752940.20k  1767321.94k  1770212.01k  1768281.43k
aes-192 cbc    1400010.40k  1496414.83k  1516962.99k  1527643.82k  1529834.15k  1527563.26k
aes-256 cbc    1222067.79k  1296972.50k  1313348.18k  1321350.83k  1322947.93k  1321850.20k
blowfish cbc   1384982.01k  1500548.63k  1529793.02k  1540091.22k  1540937.05k  1540767.74k

Intel 的 m5.4xlarge：

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
md5            1370869.17k  3276978.66k  5929591.13k  7441276.93k  8026330.45k  8071796.05k
sha256          592719.47k  1325135.04k  2506009.09k  3184234.50k  3455729.66k  3480365.74k
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128 cbc    1060996.96k  1121951.87k  1135376.21k  1141487.96k  1143270.06k  1143499.43k
aes-192 cbc     890438.97k   934047.98k   943446.44k   947576.49k   948857.51k   949026.82k
aes-256 cbc     768686.53k   800152.85k   806883.93k   809804.12k   810784.09k   810937.00k
blowfish cbc   1735490.97k  1884059.78k  1923876.10k  1932711.94k  1934477.99k  1928680.79k

Intel 的 c5.4xlarge：

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
md5            1501870.92k  3593434.20k  6503591.25k  8162811.90k  8804605.95k  8855147.86k
sha256          650179.22k  1453635.18k  2749318.83k  3492912.13k  3791164.76k  3818105.51k
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128 cbc    1163898.98k  1230539.07k  1244414.63k  1252080.98k  1254110.55k  1254206.12k
aes-192 cbc     976610.23k  1024570.03k  1034886.66k  1039442.26k  1040872.79k  1041143.13k
aes-256 cbc     843184.42k   877695.30k   885125.46k   888408.06k   889503.74k   889766.83k
blowfish cbc   1877162.34k  2056925.74k  2107008.26k  2119893.67k  2121979.22k  2115720.53k

這些數字頗有趣的... 看起來 ARM 上面應該有對某些演算法加速，使得常見的情境會快很多。不過如果是其他應用的話看起來就會比較辛苦了... 目前就價錢來看未必有絕對的優勢，還是得看應用來決定。

Cloudflare 的 jpegtran 在 ARM 上面的表現

Cloudflare 花了不少力氣在 ARM 的伺服器上 (可以參考「Cloudflare 用 ARM 當伺服器的進展...」，或是更早的「Cloudflare 測試 ARM 新的伺服器」這篇)，最近在 ARM 上發現 jpegtran 的效能不是太好，花了不少力氣最佳化，發現有意外收穫：「NEON is the new black: fast JPEG optimization on ARM server」。

他們設的低標是讓每個 core 的效能大約在 Xeon 的 50%，但發現只有 26% 左右的效能：

Ideally we want to have the ARM performing at or above 50% of the Xeon performance per core. This would make sure we have no performance regressions, and net performance gain, since the ARM CPUs have double the core count as our current 2 socket setup.

In this case, however, I was disappointed to discover an almost 4X slowdown.

而他就想到這些圖形運算的程式應該早就在使用各種 SIMD 指令集加速，於是作者就想到，把 SSE 的最佳化部份 porting 到 ARM 上面的 NEON 說不定會有很大的幫助：

Not one to despair, I figured out that applying the same optimizations I did for Intel would be trivial. Surely the NEON instructions map neatly to the SSE instructions I used before?

而 porting 完後重新測試發現達到了 66% 的效能，已經超過本來的目標... 另外在批次處理中，也比 Xeon 快了：

繼續發研究時又發現 NEON 有一些在 SSE 沒有的指令 (沒有相似功能)，也許能提供更進一步的加速：

While going over the ARMv8 NEON instruction set, I found several unique instructions, that have no equivalent in SSE.

如果再把這些指令實做出來，會發現單 core 的效能已經到 Xeon 的 83%，而批次的速度又提昇了不少：

最後是整台伺服器都跑滿時的測試，會發現整台的效能差不多 (其實 ARM 的版本還贏一些)，但吃電量不到一半，而就算只拿他們常態在跑的 4 workers 來看 (應該是為了 latency 問題)，用電效率來到 6.5 倍：

With the new implementation Centriq outperforms the Xeon at batch reduction for every number of workers. We usually run Polish with four workers, for which Centriq is now 1.3 times faster while also 6.5 times more power efficient.

這篇在提醒之後在 ARM 上寫最佳化時，不要只從 SSE porting 到 NEON，要多看一下有沒有其他指令集是有幫助的...

Cloudflare 用 ARM 當伺服器的進展...

在 Twitter 上看到 Matthew Prince (Cloudflare 的創辦人與現任 CEO) 提到了目前的進展，貼出一張兩者用電量的差距 (235W 與 150W)：

兩者差了 85W，如果以五年來算就差了 3723 度的電，另外再考慮 PUE 與機櫃空間租用的成本，長期應該是頗有機會換掉原來的 x86 系統。反過來看，短期有轉換測試成本以及 (可能會有的) 較高的故障率 (畢竟是白老鼠 XD)，再來是機器本身價錢差距，這些都是會想要知道的...

在 tweet 後 Matthew Prince 有回答一些問題，另外可以看到後續會有更多細節會整理出來，但感覺應該是調整的差不多決定會換過去了？這邊算是延續去年十一月「Cloudflare 測試 ARM 新的伺服器」這篇所做的事情，當時他們拿到 ARM 的工程板在測試，就已經跟 Xeon 打的差不多 (有輸有贏)，現在應該又改善更多...

看 retweet 數可以看出來大家還滿期待的，畢竟 ARM 上面的 Linux 本來就因為行動裝置很熱，現在主要還是差在有沒有穩定的伺服器可以用。

Spectre 與 Meltdown 兩套 CPU 的安全漏洞

The Register 發表了「Kernel-memory-leaking Intel processor design flaw forces Linux, Windows redesign」這篇文章，算是頗完整的說明了這次的安全漏洞 (以 IT 新聞媒體標準來看)，引用了蠻多資料並且試著說明問題。

而這也使得整個事情迅速發展與擴散超出本來的預期，使得 Google 的 Project Zero 提前公開發表了 Spectre 與 Meltdown 這兩套 CPU 安全漏洞。文章非常的長，描述的也比 The Register 那篇還完整：「Reading privileged memory with a side-channel」。

在 Google Project Zero 的文章裡面，把這些漏洞分成三類，剛好依據 CVE 編號分開描述：

  • Variant 1: bounds check bypass (CVE-2017-5753)
  • Variant 2: branch target injection (CVE-2017-5715)
  • Variant 3: rogue data cache load (CVE-2017-5754)

前兩個被稱作 Spectre，由 Google Project Zero、Cyberus Technology 以及 Graz University of Technology 三個團隊獨立發現並且回報原廠。後面這個稱作 Meltdown，由 Google Project Zero 與另外一個團隊獨立發現並且回報原廠。

這兩套 CPU 的安全漏洞都有「官網」，網址不一樣但內容一樣：spectreattack.com 與 meltdownattack.com。

影響範圍包括 Intel、AMD 以及 ARM，其中 AMD 因為架構不一樣，只有在特定的情況下會中獎 (在使用者自己打開 eBPF JIT 後才會中)：

(提到 Variant 1 的情況) If the kernel's BPF JIT is enabled (non-default configuration), it also works on the AMD PRO CPU.

這次的洞主要試著透過 side channel 資訊讀取記憶體內容 (會有一些條件限制)，而痛點在於修正 Meltdown 的方式會有極大的 CPU 效能損失，在 Linux 上對 Meltdown 的修正的資訊可以參考「KAISER: hiding the kernel from user space」這篇，裡面提到：

KAISER will affect performance for anything that does system calls or interrupts: everything. Just the new instructions (CR3 manipulation) add a few hundred cycles to a syscall or interrupt. Most workloads that we have run show single-digit regressions. 5% is a good round number for what is typical. The worst we have seen is a roughly 30% regression on a loopback networking test that did a ton of syscalls and context switches.

KAISER 後來改名為 KPTI，查資料的時候可以注意一下。

不過上面提到的是實體機器，在 VM 裡面可以預期會有更多 syscall 與 context switch，於是 Phoronix 測試後發現在 VM 裡效能的損失比實體機器大很多 (還是跟應用有關，主要看應用會產生多少 syscall 與 context switch)：「VM Performance Showing Mixed Impact With Linux 4.15 KPTI Patches」。

With these VM results so far it's still a far cry from the "30%" performance hit that's been hyped up by some of the Windows publications, etc. It's still highly dependent upon the particular workload and system how much performance may be potentially lost when enabling page table isolation within the kernel.

這對各家 cloud service 不是什麼好消息，如果效能損失這麼大，不太可能直接硬上 KPTI patch... 尤其是 VPS，對於平常就會 oversubscription 的前提下，KPTI 不像是可行的方案。

可以看到各 VPS 都已經發 PR 公告了 (先發個 PR 稿說我們有在注意，但都還沒有提出解法)：「CPU Vulnerabilities: Meltdown & Spectre (Linode)」、「A Message About Intel Security Findings (DigitalOcean)」、「Intel CPU Vulnerability Alert (Vultr)」。

現在可以預期會有更多人投入研究，要怎麼樣用比較少的 performance penalty 來抵抗這兩套漏洞，現在也只能先等了...