Ubuntu Weekly Recipe

第721回新型ベアボーンキットであるDeskMeetと最新CPUであるAlder Lakeで夢のパワフルUbuntuライフ

ASRockからDeskMeet B660およびX300という製品が発売されました。これは「グラフィックボードも搭載できるベアボーン」という扱いの製品で、8LほどのPCIe x16のスロットが搭載されているにしては小さめの筐体に、4スロットのDIMMや複数のSATAポートが接続できるなど、拡張性が高い構成になっています。今回はこのDeskMeet B660とIntelの第12世代Core(Alder Lake)にUbuntuをインストールしてみましょう。

DeskMiniがMaxになって生まれたDeskMeet

DeskMeetの登場はちょうど一年ほど前のCOMPUTEX TAIPEI 2021までさかのぼります。オンラインで開催された当該イベントのASRockブースで「DeskMiniにグラフィックボード用のPCIeスロットを搭載したDeskMini MAXが発表されたのです。DeskMiniと言えば、ASRock製の名機とのほまれ高い人気ベアボーンシリーズで、本連載でも第696回のUbuntuでもWi-Fi 6を使用するにおいて対向のデバイスとしてしれっと登場しています。

その後半年ぐらい音沙汰がなかったのですが、Intel CPUへの対応や5インチベイの必要性や10L弱の容量、⁠MiniなのかMAXなのかわかりづらい名前」とか諸々リファインして、2022年1月に「DeskMeet」がアナウンスされます。ポイントは「そこそこの価格の筐体に、PCIeスロットがあり、2.5/3.5インチSATAストレージを載せれること」でしょう。

主なターゲットはそこそこ強めのグラフィックボード(dGPU)カードを載せたいけれども、場所は取りたくないというわがままなゲームユーザーと思われます。また、他にも「10GbE以上のNICを搭載する」とか「ちょっとしたストレージサーバーにする」とかFPGAの載ったPCIeデバイスを使うとかいろいろな用途も考えられます。特に家庭内サーバー用途であればグラフィックボードは不要になるため、内蔵GPU付きのCPUを載せて、PCIeスロットやSATAポートを活用する方法が有用になってくるでしょう。いずれにせよ「サイズが小さく場所を取らない」ことが、⁠ちょっと買ってみるか」という動機に繋がるのです[1]⁠。

図1 Raspberry Piと比べればその小ささは一目瞭……然……?
図1

ただしPCIeカードは長さが20cmまでであること、スロット自体はx16がひとつしかなく、カードの高さは2枚分までであることに注意が必要です。また、2台目の3.5インチSATAストレージ、もしくは3台目の2.5インチSATAストレージを接続する場合は、PCIeスロットは使えなくなる(干渉してしまう)旨も覚えておきましょう。ちなみにストレージとしては他にもM.2 NVMe用ソケットも利用可能です[2]⁠。

ベアボーンなのでCPUをはじめとして各パーツは別途購入が必要です。パーツの選定や組立方法は自作PCに強い執筆者による、丁寧な記事がたくさん存在するはずなのでそちらを参照してください。組立自体そこまで難しくはありません[3]⁠。

今回は次のようなパーツで組み立ててみました。

機能 メーカー 型番 備考
CPU Intel Core i9-12900 16C/24T 65W
CPUクーラー ID-COOLING IS-40X-V2 空冷
メモリー Crucial CT2K32G4DFD832A DDR4-3200 32GBx2
M/B ASRock B660-ITX ITX
ストレージ Crucial P5 Plus 1TB PCIe 4.0x4
GPU Intel UHD Graphics 770 iGPU

まずはAlder Lakeを試すのが目的だったので、PCIeスロットもSATAポートも使っていません[4]⁠。あとCPUのMTP(Maximum Turbo Power)に対してクーラーが心もとない感じがしますが、これは今後要検討課題としています[5]⁠。一応簡易水冷も可能なものの、そうするとケースファンを取り付ける必要があるため、PCIeスロットが事実上使えなくなります。

Ubuntu 22.04 LTSでの動作確認

組み立てたらまずは動作確認です。Ubuntuを使った動作確認の定番は次の記事が参考になるでしょう。

ちなみにDeskMeet B660のほうは第12世代のIntel Core(Alder Lake)が必須になるため、Ubuntu 22.04 LTS以降が事実上必須です。ただし動作確認の手順そのものは上記記事と大きく違いはありません。

図2 システムモニター上はきちんと24スレッド見えているし、iGPUも認識している模様
図2
図3 CPU-Xだと「Rocket Lake」と誤って認識されてしまっている
図3
図4 P5 PlusのM.2 NVME SSDも十分な性能が出ている
図4

CPU-XがRocket Lakeとして誤認識されてしまっているのは、利用しているlibcpuid側の問題のようです。

本連載では過去にもいろいろな記事でベンチマーク等を取っています。似通った製品を所持しているのであれば、参考になるかもしれません。直近のものをリストアップしておきました。

もちろんGPUも問題なく動いています。ただしDeskMeetにあえてUbuntu入れる用途だと、デスクトップよりは家庭内サーバーマシンのほうが多いかもしれません。

第12世代Intel CoreのAlder Lake

DeskMeet B660でUbuntuを動かす上で一番の障害になりそうなのが、実は「CPU」です。

DeskMeet B660はCPUソケットとして「LGA1700」を採用しています。このため、2022年6月時点では第12世代Intel CoreのAlder Lakeしかサポートしていません。Alder Lakeは昨年11月にリリースされたばかりの最新のCPUとなります。

Intelは比較的新しい製品に対応するためのコードを、その発売前から積極的にLinuxカーネルに取り込むよう取り組んでいます。よって発売直後の状態でも、新しいカーネルを使えばそれなりに動くのです。実際、Ubuntu 22.04 LTSで採用しているLinux Kernel 5.15は、2021年10月31日にリリースされたものです。つまりAlder Lakeの正式発売日直前です。このカーネルでも、Alder Lakeそのものは認識しますし、iGPUも含めて特に問題なく動きます。

ただしAlder Lakeに関してはこれまでにない特殊な事情があります。それがIntel Hybrid Technologyの採用」です。これは、高性能コア(Performance Cores:P-Cores)と高効率コア(Efficient Cores:E-Cores)の二種類のコアを搭載することで、高性能と低消費電力を両立させようという目論見です[6]⁠。Intel Hybrid Technology自体はもう少し前から存在しますが、デスクトップ向けCPUとして広く採用されたのはAlder Lakeからとなります。なお、E-Coreに関しては、デスクトップ向けだとCore i5のK付きか、Core i7以上のみ存在するようです。逆に省電力が重視されるモバイル向けは、全モデルでE-Coreを搭載しており、P-Coreのほうが数が少なめに設定されています。

さて、Intel Hybrid Technologyがその真価を発揮するためには、⁠どのタスクがP-Coreを使い、どのタスクはE-Coreで動かすのか」を効率的に判断し采配しなければなりません。そこでAlder Lakeではさらに、Intel Thread Directorなる機能が追加されました。Windowsを含むOSは、この機能を使ってどのタスクをどのコアで動かすか判断するわけです。Intelの開発者向けドキュメントでは、この機能にアクセスする部分をHardware Feedback Interface(HFI)と呼んでおり、どのコアがどんな状態であるかをOSがわかるようになっています。

このIntel HFIを使うになったのが、Linux Kernel 5.18からとなります。OSはこの情報に基づき、忙しいそうなコアにはタスクを割り当てないといった処理が簡単に実現できるようになりました[7]⁠。

いずれにせよUbuntu 22.04 LTSのカーネルでは、Alder Lakeの真価は発揮できません。現状はハイパースレッディングに対応したCPUコアと、⁠Core i5の上位以上であれば)ハイパースレッディングに非対応のCPUコアが混在しているように見えるだけです。カーネルのスケジューラーは、単にコアが多めのCPUとして作業を割り振ることになります。とは言え、Alder LakeのうちE-Coreが搭載されているモデルは、E-Coreの分だけ「純増」に近いので、それでも十分に性能は向上するでしょう[8]⁠。

たとえばUbuntu 22.04 LTSの場合、CPUの各コアは次のようになっていました。

$ lscpu --all --extended
CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE    MAXMHZ   MINMHZ      MHZ
  0    0      0    0 0:0:0:0          yes 5100.0000 800.0000 2400.000
  1    0      0    0 0:0:0:0          yes 5100.0000 800.0000 2400.000
  2    0      0    1 4:4:1:0          yes 5100.0000 800.0000 2400.000
  3    0      0    1 4:4:1:0          yes 5100.0000 800.0000 2400.000
  4    0      0    2 8:8:2:0          yes 5100.0000 800.0000 2400.000
  5    0      0    2 8:8:2:0          yes 5100.0000 800.0000 2400.000
  6    0      0    3 12:12:3:0        yes 5100.0000 800.0000 2400.000
  7    0      0    3 12:12:3:0        yes 5100.0000 800.0000  800.135
  8    0      0    4 16:16:4:0        yes 5100.0000 800.0000 2400.000
  9    0      0    4 16:16:4:0        yes 5100.0000 800.0000 2400.000
 10    0      0    5 20:20:5:0        yes 5100.0000 800.0000 2400.000
 11    0      0    5 20:20:5:0        yes 5100.0000 800.0000 2400.000
 12    0      0    6 24:24:6:0        yes 5100.0000 800.0000 2400.000
 13    0      0    6 24:24:6:0        yes 5100.0000 800.0000 2400.000
 14    0      0    7 28:28:7:0        yes 5100.0000 800.0000 2400.000
 15    0      0    7 28:28:7:0        yes 5100.0000 800.0000 2400.000
 16    0      0    8 32:32:8:0        yes 3800.0000 800.0000 2400.000
 17    0      0    9 33:33:8:0        yes 3800.0000 800.0000 2400.000
 18    0      0   10 34:34:8:0        yes 3800.0000 800.0000 2400.000
 19    0      0   11 35:35:8:0        yes 3800.0000 800.0000 2400.000
 20    0      0   12 36:36:9:0        yes 3800.0000 800.0000 2400.000
 21    0      0   13 37:37:9:0        yes 3800.0000 800.0000 2400.000
 22    0      0   14 38:38:9:0        yes 3800.0000 800.0000 2400.000
 23    0      0   15 39:39:9:0        yes 3800.0000 800.0000 2400.000

MAXMHZが高く、CORE列に同じ数字が並んでいるものがハイパースレッディング対応のP-Coreです。つまりP-Coreが最初に割り当てられて、末尾にE-Coreが固まっている状態でした。このとき何か負荷の高いタスクを実行すると優先的にP-Coreが使われます。これは単にMAXMHZが高いものを優先的に使う措置のようです。

具体的に試してみましょう。単にCPUに負荷をかけるなら、stress-ngが便利です。ついでにCPUの使用率を見るために第697回でも紹介した高機能モニタリングツールglancesもインストールしておきます。

$ sudo apt install stress-ng glances

たとえば3個ほどCPUを動かすタスクを立ち上げてみましょう。

$ stress-ng -c 3 &

別のターミナルでglancesを起動しておきます。

$ glances

起動した状態だとCPUの使用率はまとめて表示されるため、topコマンドと同じく「1」を入力して、すべてのCPUを表示するようにしておきます。もしくはglances -1とオプションを付けて起動するのでもかまいません。そうするとP-Coreの中から(つまりCPU0からCPU15までの中から⁠⁠、任意の3コアの使用率が100%になっていることがわかるでしょう。

図5 使用されるコアはそのタイミングで異なる
図5

この状態でずっと眺めていると、たまに100%のコアが遷移することにも気づくはずです。ただし使用されるのは常にP-Coreで、E-Core(CPU16以降)は使われないこともわかるでしょう。また、P-Coreでも奇数番号のコアは使われないという結果になります。

さらにタスクを5個追加してみます。

$ stress-ng -c 5 &
図6 きれいにP-Coreの偶数番号のコアのみ使われる
図6

これはおそらく単純に性能の高いCPUコアを順番に使っているというだけでしょう。さて、ここでさらにもう1タスク追加してみます。

$ stress-ng -c 1 &
図7 P-Coreの奇数番号ではなく、E-Coreを使うようになった
図7

このあとそのまま眺めていると、最後の1タスクはE-Core間を遷移するという結果になりました。結局このあとはE-Coreを使い切るまで、つまりstress-ngのタスクが16個を超えるまで、P-Coreの奇数番号が使われることはありませんでした。

図8 16タスク動かした状態でも、P-Coreは半分の論理コアしか使われない
図8

これは日常的な処理も同じ傾向で、topやglancesで見ているとよっぽどいろいろと動かさない限りはP-Coreの偶数番号とE-Coreのみを使い、P-Coreの奇数番号の使用率はほとんどあがりません。E-Coreもそこそこの性能はあるので、ほとんど実害はないのですが、若干もったいない気もします。このあたりを解決するために、Intel Thread Directorがいるのでしょう。

ちなみにさすがにstress-ngで回していると90度を超えてくることもあるようです。今回の構成では、全力を出すには冷却が間に合っていないことになります。結果的にCPUの周波数も抑えめになっていました。

$ lscpu --all --extended
CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE    MAXMHZ   MINMHZ      MHZ
  0    0      0    0 0:0:0:0          yes 5100.0000 800.0000 1991.872
  1    0      0    0 0:0:0:0          yes 5100.0000 800.0000 2400.000
  2    0      0    1 4:4:1:0          yes 5100.0000 800.0000 1989.378
  3    0      0    1 4:4:1:0          yes 5100.0000 800.0000 2400.000
  4    0      0    2 8:8:2:0          yes 5100.0000 800.0000 1992.173
  5    0      0    2 8:8:2:0          yes 5100.0000 800.0000 2000.079
  6    0      0    3 12:12:3:0        yes 5100.0000 800.0000 1998.079
  7    0      0    3 12:12:3:0        yes 5100.0000 800.0000 2400.000
  8    0      0    4 16:16:4:0        yes 5100.0000 800.0000 2000.000
  9    0      0    4 16:16:4:0        yes 5100.0000 800.0000 2400.000
 10    0      0    5 20:20:5:0        yes 5100.0000 800.0000 2000.000
 11    0      0    5 20:20:5:0        yes 5100.0000 800.0000 2400.000
 12    0      0    6 24:24:6:0        yes 5100.0000 800.0000 1998.070
 13    0      0    6 24:24:6:0        yes 5100.0000 800.0000 2400.000
 14    0      0    7 28:28:7:0        yes 5100.0000 800.0000 2000.001
 15    0      0    7 28:28:7:0        yes 5100.0000 800.0000 2400.000
 16    0      0    8 32:32:8:0        yes 3800.0000 800.0000 1600.002
 17    0      0    9 33:33:8:0        yes 3800.0000 800.0000 1600.001
 18    0      0   10 34:34:8:0        yes 3800.0000 800.0000 1599.999
 19    0      0   11 35:35:8:0        yes 3800.0000 800.0000 1599.999
 20    0      0   12 36:36:9:0        yes 3800.0000 800.0000 1600.000
 21    0      0   13 37:37:9:0        yes 3800.0000 800.0000 1600.000
 22    0      0   14 38:38:9:0        yes 3800.0000 800.0000 1600.000
 23    0      0   15 39:39:9:0        yes 3800.0000 800.0000 1600.001

軽く挙動を確認したところで今回はここまでです。次回以降ではせっかく購入したDeskMeetをもう少し活用する何かを考えることにしましょう。

おすすめ記事

記事・ニュース一覧