Go to Qiita Advent Calendar 2024 Top
LoginSignup
40
27

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

FUJITSUAdvent Calendar 2023Day 24
@YasunoriGoto1

意外と知られていない、Linuxのメモリホットプラグのインタフェースについて

Last updated at Posted at 2023-12-24

0.はじめに

0.1 今年を振り返って

この記事はFujitsu Advent Calendar 2023 の24日目の記事です。
なお、本記事は個人の意見に基づくものであり、組織を代表するものではありません。

今年もAdvent Calendarの季節となりましたね。皆様お変わりないでしょうか？ 私の方はというと、全体的に多忙ではありましたが、夏には国際学会IEEE NVMSAでの発表、秋から年末にかけて海外出張やOpen Source Summit Japanでの講演など、今年後半は怒涛のように仕事がくる状態になってました。おまけに 「Linus Torvaldsと会談せよ」 というミッションまで降ってきてしまい、正直どうなることかと思いました。人生、何が起こるかわからないものです。学生時代、英語は超苦手だったのに…。

0.2 今年の記事について

さて、例年このAdvent Calendarでは、不揮発メモリやCXLについて私はまとめてきたのですが、今年は前述のとおり、IEEE NVMSA 2023やOpen Source Summit Japan 2023などの国際カンファレンスなど色々な場でCXLについて発表する機会があり、新たにQiitaで記載できることはあまり多くはありません。
（とりあえず、OSSJの発表資料はこちらに置いておきます。）

このため、CXLそのものの動向や解説などは一旦おいておいて、今年はCXLのメモリプール1機能でも使うであろう、Linuxのメモリホットプラグのインタフェースについて改めて解説しておこうと思います。

このLinuxのメモリホットプラグという機能は、実はもう10年以上前から存在する機能です。私をはじめとして様々な人が2004年頃2から開発していて2007年頃にはkernelに取り込まれています。そのときに体験した苦労話について「七転び八起きのLinuxカーネルコミュニティ開発体験記」として日経の記事3にまとめたこともあります。このため、私にとっては非常に思い入れのある機能です。

更に、現在でもコミュニティで機能強化されていて、ドキュメントも以下のようにきちんとメンテナンスされています。最初にこのファイルを作ったのは恐らく私なのですが、いろいろあったのか、私の名前は空行にしか残っていないという状態です。

ac3332c44767b Documentation/admin-guide/mm/memory-hotplug.rst (David Hildenbrand     2021-09-07 19:54:49 -0700   1) ==================
ac3332c44767b Documentation/admin-guide/mm/memory-hotplug.rst (David Hildenbrand     2021-09-07 19:54:49 -0700   2) Memory Hot(Un)Plug
ac3332c44767b Documentation/admin-guide/mm/memory-hotplug.rst (David Hildenbrand     2021-09-07 19:54:49 -0700   3) ==================
6867c9310d5da Documentation/memory-hotplug.txt                (Yasunori Goto         2007-08-10 13:00:59 -0700   4) 
ac3332c44767b Documentation/admin-guide/mm/memory-hotplug.rst (David Hildenbrand     2021-09-07 19:54:49 -0700   5) This document describes generic Linux support for memory hot(un)plug with
ac3332c44767b Documentation/admin-guide/mm/memory-hotplug.rst (David Hildenbrand     2021-09-07 19:54:49 -0700   6) a focus on System RAM, including ZONE_MOVABLE support.
6867c9310d5da Documentation/memory-hotplug.txt                (Yasunori Goto         2007-08-10 13:00:59 -0700   7) 
6bf53999a3a26 Documentation/admin-guide/mm/memory-hotplug.rst (Mike Rapoport         2018-10-05 01:11:00 +0300   8) .. contents:: :local:
6bf53999a3a26 Documentation/admin-guide/mm/memory-hotplug.rst (Mike Rapoport         2018-10-05 01:11:00 +0300   9) 
ac3332c44767b Documentation/admin-guide/mm/memory-hotplug.rst (David Hildenbrand     2021-09-07 19:54:49 -0700  10) Introduction
ac3332c44767b Documentation/admin-guide/mm/memory-hotplug.rst (David Hildenbrand     2021-09-07 19:54:49 -0700  11) ============
c18c1cce0c1a0 Documentation/memory-hotplug.txt                (Mauro Carvalho Chehab 2017-05-14 22:52:22 -0300  12) 
ac3332c44767b Documentation/admin-guide/mm/memory-hotplug.rst (David Hildenbrand     2021-09-07 19:54:49 -0700  13) Memory hot(un)plug allows f

しかしながら、そのわりにはこの機能が 一般の人にはこの機能があまり知られていない ということに最近気が付きました。memory hotplugを使えば簡単に実験できることを、その機能の存在自体を知らなかったため、研究職の方でもこれを使わずに苦労して実験いたことを耳にしたぐらいです。さすがにこれは良くないと感じたというのが今年の記事を書く気になった動機です。

それでははじめましょう。

1. 想定とする読者やハードウェアについて

1.1 対象読者

今から述べるインタフェースは、どちらかというとある程度kernelについて知識のある人向けのインタフェースです。例えば以下のような方です。

  • この機能を使うシステム、ユーザプロセスやコマンドなどの開発者
  • この機能でシミュレーションなど実験を行うことができる研究・開発者

これらのインタフェースはエンドユーザ向けのものとはなっていません。メモリホットプラグに対応したハードウェアのエンドユーザの方は、そのハードウェアに添付されたエンドユーザ向けの案内やコマンドなどがあるかもしれません。ご確認の上、そちらに従ってください。

1.2 対応ハードウェア

意外と知られていませんが、これらのメモリホットプラグの機能の一部は、実は一般的なサーバやデスクトップマシン、VMゲストなどでも試すことは可能 です。
テストなどで、一時的にメモリの容量を減らしたいとか、システム内のメモリ構成を変更したい時などにこのメモリホットプラグの機能を使うことができます。本記事では、一般的なPCで使い方を試す方法を中心にご紹介します。

もちろん実際にmemoryがhotplugできる対応ハードがあった方や、より実践的な操作ができますが、上記のような身近な環境でも使えることは覚えておいてください。

また、CXLでの操作についても簡単にご紹介します。ただ実際には、この機能の完成度が上がってくるのはこれからになると思われるので、新しい情報が今後出てくるかもしれません。（私もこの辺りはまだ十分に試せていません）。

本記事の実行例における動作環境はディストリビューションはubuntu 20.04LTSですが、RedHat系列のOSでも大きくは変わらないはずです。また、ハードは20GiBのメモリを搭載した筆者のNote PCで実施しています。

2. メモリホットプラグの大まかなシーケンス

大きく分けて以下の2段階になっています。

Memory Hotaddの場合

  1. ハード的にメモリを認識(a)
    この段階では、追加されたメモリに物理アドレスが割り当てられた状態です。しかしOSのメモリ管理機構がこの領域を管理するためのデータ構造を初期化していない状態です。したがって、OSやユーザープロセスからはこのメモリはまだ利用することができません。
  2. OSへメモリを組み込み、kernel/driverやプロセスに利用可能にさせる(b)
    OSのメモリ管理機構が上記の初期化を終えた状態です。この段階を踏まえることで、OS自身やユーザープロセスから、追加されたメモリを利用することが可能となります。

Memory Hotremoveの場合

  1. OSの管理下からメモリを解放し、プロセスから利用できないようにする(b)
    上記とは逆に、OSの制御からメモリを解放する段階です。プロセスが利用中の場合、可能であればmemory migration(後述)の力で他のメモリ領域にこっそりデータを移動します。その後、メモリ管理機構からこの領域を解放します。CPUからはまだこのメモリの物理アドレスは認識できていますが、OSからは切り離されたため、このメモリを利用することはできなくなります。

  2. ハード的にメモリを切り離し(a)
    ハード・ファームウェアにこの領域の返却を通知します。これにより、CPUから当該領域の物理アドレスにはアクセスできなくなります。

memory_hotplug_flow.png

上記を分類しなおすと、メモリホットプラグの操作は以下の2段階に分かれていることになります。

操作a. ハード・ファーム的なつけ外しの段階
操作b. OSへの組み込み・切り離し

先にbについて解説しますが、bはOSの仕組みとして動作し、ハード・ファームは介入しません。この操作が前述した、 特殊なハード・ファームは必要ではなく一般的なPCやサーバー、VMゲストなど一般的な環境でも動作する 箇所になります。

一方、aについてはハード・ファームウェアの力でメモリをつけ外しする機能なので、基本的にはプラットフォームがメモリーホットプラグをサポートしていないと動作できません。また、そのしくみに対応するためのドライバ(PCIeのhotplugのドライバや、ACPIのhotplugのドライバなど)が必要です。

ただし本記事では、HotAddについてちょっとした設定や操作によって、それに近い体験ができる方法を紹介します。

筆者は試したことはありませんが、QEMUの操作でもmemory hotplugの操作が可能なようです。本記事内では使いませんが、その方法が記載されたドキュメントについては後述します。

なお、このa.ハード・ファーム的なつけ外しについては、CXLでは以下の2通りの仕組みが仕様上定義されています。（本記事ではこの仕様についてはあまり触れません）

  1. PCIeのhotplugの仕様に基づいた、デバイス単位のhotplug
  2. CXL 3.0以降で導入されたDynamic Capacity Deviceによる、メモリデバイスの一部をあり当てる形のhotplug

3. メモリホットプラグのインタフェース

では、インタフェースを少しずつ触って体験してみましょう。

3.1 OSへの組み込み・切り離しの基本的な操作

まず、身近に確認できる「b.OSへの組み込み・切り離し」について、そのインタフェースを見ていきましょう。以下のようなsysfsのディレクトリの配下にmemory hotplug関係のファイルやディレクトリが配置されてます。これがインタフェースとなります。

これ以降の操作はroot権限で行っていることに注意してください

# pwd
/sys/devices/system/memory
# ls
 ls
auto_online_blocks  memory114  memory133  memory152  memory171  memory47  memory66  memory85
block_size_bytes    memory115  memory134  memory153  memory172  memory48  memory67  memory86
hard_offline_page   memory116  memory135  memory154  memory18   memory49  memory68  memory87
memory0             memory117  memory136  memory155  memory2    memory5   memory69  memory88
memory1             memory118  memory137  memory156  memory3    memory50  memory7   memory89

(中略)

memory109           memory128  memory147  memory166  memory41   memory60  memory8   memory99
memory11            memory129  memory148  memory167  memory42   memory61  memory80  power
memory110           memory13   memory149  memory168  memory43   memory62  memory81  probe
memory111           memory130  memory15   memory169  memory44   memory63  memory82  soft_offline_page
memory112           memory131  memory150  memory17   memory45   memory64  memory83  uevent
memory113           memory132  memory151  memory170  memory46   memory65  memory84

まずは、上記のうち以下のファイルの内容を出力してみます。

# cat block_size_bytes
8000000

これは、メモリホットプラグの(b)の操作をどれくらいの単位で行うかの表示です。以後、この単位を便宜上、メモリブロックと記述します。この環境では0x8000000と表示されているわけですから１つのメモリブロックのサイズが128MiByteとなっていることがわかります。このサイズは基本的にアーキテクチャごとに異なり、 基本的には 変更不可能な固定値です。

筆者がmemory hotplugの開発に関わっていた頃、言い換えるとLinuxのmemory hotplug機能が初めて搭載された頃はx86-64はこの128MiB固定、ia64では1GiB、powerpcでは(筆者の記憶では)16MiB固定のサイズとなっていました。この値は固定値のほうが、以下のような理由でいろいろな面で都合がよかったためです。

  • kernel内部の実装がシンプルになり、高速な処理が可能となるため都合がよいこと
  • powerpcではプラットフォームの力で、16MiB単位という小さな単位でmemory hotplugが出来ること
  • ia64ではもっと大きな単位でメモリがhotplugされ、またメモリの最大容量が当時はx86-64よりもかなり大きかったこと

しかし、現在では当時とは状況がかわってきており、x86-64サーバのメモリ搭載量もずいぶん大きくなってきました。このため、今ではkernelが起動時にメモリブロックサイズとしてどれくらいのサイズがちょうど良いかをある程度判定して決めるという形になっています。搭載されているメモリ量など様々な状況によって適切なサイズが変わってくるためです。
例えば、筆者の別の環境ではこのサイズが2GiBのサイズになっています。

# cat block_size_bytes 
80000000

x86_64では以下の判定箇所で決めています。興味が有る人は調べてみてください。

arch/x86/mm/init_64.c

static unsigned long probe_memory_block_size(void)
{
        unsigned long boot_mem_end = max_pfn << PAGE_SHIFT;
        unsigned long bz;

        /* If memory block size has been set, then use it */
        bz = set_memory_block_size;
        if (bz)
                goto done;

        /* Use regular block if RAM is smaller than MEM_SIZE_FOR_LARGE_BLOCK */
        if (boot_mem_end < MEM_SIZE_FOR_LARGE_BLOCK) {
                bz = MIN_MEMORY_BLOCK_SIZE;
                goto done;
        }
       (以下略)

さて、/sys/devices/system/memoryのディレクトリには、memory###の数字を持つディレクトリがありますが、この###の数字の部分は、物理アドレスに対して、このblock_size_bytesの値を割った値となっています。つまり、memory0のディレクトリは物理アドレス0x0の位置のメモリから128MiByteのサイズの領域を、memory8のディレクトリは 8 x 128MiB = 1024MiBから128MiBのサイズの物理アドレスの領域を管理するディレクトリとなっているわけです。

それでは、例としてmemory160のディレクトリの中身を見てみましょう。160*128MiB=20GiBなので、物理アドレスとして20GiBの物理アドレスから128MiByteのサイズのメモリブロック領域を管理するためのディレクトリです4。

# pwd
/sys/devices/system/memory/memory160
# ls -al
合計 0
drwxr-xr-x   3 root root    0 12月 23 11:14 .
drwxr-xr-x 163 root root    0 12月 23 11:14 ..
lrwxrwxrwx   1 root root    0 12月 23 11:27 node0 -> ../../node/node0
-rw-r--r--   1 root root 4096 12月 23 11:27 online
-r--r--r--   1 root root 4096 12月 23 11:27 phys_device
-r--r--r--   1 root root 4096 12月 23 11:27 phys_index
drwxr-xr-x   2 root root    0 12月 23 11:27 power
-r--r--r--   1 root root 4096 12月 23 11:27 removable
-rw-r--r--   1 root root 4096 12月 23 11:27 state
lrwxrwxrwx   1 root root    0 12月 23 11:14 subsystem -> ../../../../bus/memory
-rw-r--r--   1 root root 4096 12月 23 11:14 uevent
-r--r--r--   1 root root 4096 12月 23 11:27 valid_zones

メモリホットプラグにおいて、もっとも重要なファイルがこの中のstateというファイルです。まずはこの値を表示してみましょう。

# cat state
online

これは、この160*128MiB=20GiBの物理アドレスから始まる128MiBのメモリ領域がonline、すなわちOSによって管理されていて、プロセスにメモリが利用できる状態になっていることを示します。それでは、(b)の操作、すなわちこの領域に対してOSの切り離し操作をしてみましょう。

# echo offline > state
# cat state
offline

このように、stateのファイルに対してofflineの文字列を書き込むことにより切り離しの操作を行うことができます。ユーザープロセスがこの物理アドレスのメモリを使っていた場合は、この時にmemory migrationの機能によってほかのアドレスに移動されています。

それでは元に戻してみましょう。

# echo online > state
# cat state
online

これで、再びOSに組み込まれて、この領域が利用できる状態になりました。
これが、(b)OSへの組み込み、切り離しの最も基本的な操作になります。

3.2 切り離しを確実にするために

3.2.1 メモリが抜けなくなる要因

実は、offlineの操作は失敗することがあります。試しにmemory0のメモリブロックをofflineにしてみましょう。

# pwd
/sys/devices/system/memory/memory0
# echo online > state
-bash: echo: 書き込みエラー: 無効な引数です
# cat state
online

エラーになってしまいました。状態もonlineのままですね。これはmemoryが以下のような条件などにより、memory migrationが動作できず、offlineできない状態になっていることが原因です。

カーネルやドライバがその領域を利用している

一般的にユーザープロセスが使っているメモリについては、kernelは図に示すようなmemory migrationという機能を使って、hotplugで抜こうとしている領域からほかの場所に移動させます。これは仮想アドレスはそのままにしつつ、データが保持されているメモリの物理アドレスを変えるという機能です。

memory_migration.png

ですが、カーネルやドライバのメモリ空間はこの機能が使えません。カーネルやドライバが使うメモリの仮想アドレスは物理アドレス＋固定値(PAGE_OFFSET)という固定値で決められていて、物理アドレスをこっそりかえるということができない場合があります。また、そうでなくても割り込み禁止で動作している場合など、migraitionの時間が待てないというケースもあります。このため、これらが使っているメモリブロックをofflineしようとするとエラーになってしまうのです

ユーザプロセスのメモリが動かされないように、ドライバなどが固定している

速度を優先して、kernelをスキップして直接プロセスが使っているメモリにDMA/RDMAなどの手段でデータ転送中の場合、memory migrationを行うことはできません。物理アドレスを移動しても、転送中のハードウェアを止めることができないからです。
また、VMゲストが速度を優先してメモリを固定する場合もあるようです。このような場合もmigrationを行うことはできません。

その他

Linux Kernelのソースコードの中の ドキュメントDocumentation/admin-guide/mm/memory-hotplug.rstには、他にもメモリが抜けない状態になるような原因について、この記事よりくわしく書いてあります。興味があるかたは参照してみてください。（私もこの記事を書くにあたって初めて知ったものもあります）。

3.2.2 ZONE_MOVABLE

このような抜けないケースをできるだけ避けるため、LinuxではZONE_MOVABLEという領域を定義することができます。ZONE_MOVABLEはkernelやドライバが使うことができない領域です。
また、ユーザプロセスのメモリを動かないようにを固定する場合、利用者が適切なパラメタ(FOLL_LONGTERM)を指定していれば、固定する前にZONE_MOVABLEの外にmigrateしてから固定するように動作します。

この領域はデフォルトでは存在しませんが、kernelのブートオプションを指定することで作成できます。kernelのソースコードに付属しているドキュメントには、その指定方法が書かれています。

$ pwd
/Documentation/admin-guide
$ less kernel-parameters.txt
  :
  :
        kernelcore=     [KNL,X86,IA-64,PPC]
                        Format: nn[KMGTPE] | nn% | "mirror"
                        This parameter specifies the amount of memory usable by
                        the kernel for non-movable allocations.  The requested
                        （中略）
  :
        movablecore=    [KNL,X86,IA-64,PPC]
                        Format: nn[KMGTPE] | nn%
                        This parameter is the complement to kernelcore=, it
                        specifies the amount of memory used for migratable
                        allocations.  If both kernelcore and movablecore is
                        （後略）
  :

movablecoreはZONE_MOVABLEの領域の量を指定する方法です。kernelcoreはZONE_MOVABLE 以外 の領域の量を指定する方法です。通常はどちらかを使えば十分です。具体的な容量を指定するか、あるいは全体の容量に対する比率を％で指定します。

この指定をするということは、kernelやドライバが使えるメモリの量が通常より少なくなるということです。どれくらいの容量を指定すればよいかについては条件によって異なります。本番環境などで使いたいという場合には、この値の量の指定には本番移行前までに検証を行うなど、十分注意して使うようにしてください。

なお、ここの記述でkernelcoreにはmirrorという指定がありますが、これは特殊なプラットフォームのための指定であり、通常はまず使うことがないオプションです。この文の注釈でどういうオプションなのかを補足しておきます5。

では、このブートオプションの効果を確認してみましょう。
まず、これを指定する前のメモリの状態を確認して見ましょう。例としてmemory block 100の値を確認します。

(再起動前)
# pwd
/sys/devices/system/memory/memory100
# cat valid_zones
Normal

ではこのブートオプションを指定してシステムを起動してみましょう。50%のメモリをkernelやドライバが利用できる領域とし、 それ以外の領域 を ZONE_MOVABLE の領域として設定します。

(再起動後)
# cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-5.15.0-91-generic root=(中略) kernelcore=50%
 
# pwd
/sys/devices/system/memory/memory100
# cat valid_zones
Movable

memory100のブロックがZONE_MOVABLEに代わったことが分かります。このような設定をすることで、memoryを抜きやすくすることが可能です。

また、メモリブロックをonlineするときに、ZONE_MOVABLEにするか、それ以外の通常の領域(ZONE_NORMALなど)にするかも指定可能です。この環境において、Normalだったメモリブロックで、たまたまofflineにできるメモリブロックがありました。これをZONE_MOVABLEに変えてみましょう。以下のように操作します。

# pwd
/sys/devices/system/memory/memory85
# cat state
online
# cat valid_zones 
Normal  <------------------------------- この時点ではZONE_NORMALの領域です
# echo offline > state
# cat state
offline <------------------------------- 一旦offlineにすることが出来ました。
# echo online_movable > state <--------- onlineする領域をZONE_MOVABLEにすることを指定します
# cat state
online
# cat valid_zones 
Movable  <------------------------------ MOVABLE_ZONEの領域になりました

逆にZONE_NORMAL、すなわちkernelやドライバが使えるメモリ領域にしたい場合はonline_kernelを指定してstateに書き込むと良いです。

4. ハード・ファーム的な取付、つけ外しについて

4.1 手動での操作

基本的にはハード・ファーム的なつけ外しはメモリホットプラグに対応したプラットフォームでないと実行できないと述べましたが、以下の条件が揃っている場合、取り付けすなわちhotaddについてエミュレーション的な動作をさせることが出来ます。

  • アーキテクチャがこのエミュレーションに対応していること(kernel-6.7-rc5の時点ではx86, powerpc, sh, LoogArchが対応しているようです)
  • CONFIG_ARCH_MEMORY_PROBEがkernelコンパイル時にonになっていること。

では、このエミュレーションをちょっと実験してみましょう。20GiBあるマシンに対して、mem= のブートオプションによって、システム起動時にkernelにはメモリの半分の10GiBのみを認識させるオプションを追加し、残りはkernelが認識していない状態としています。
なお、ここでmemhp_default_state=offlineという指定も追加していますが、これについては後で説明します。

# cat /proc/cmdline 
BOOT_IMAGE=/boot/vmlinuz-6.2.0-39-generic root=(中略) kernelcore=50% mem=10G memhp_default_state=offline

# pwd
/sys/devices/system/memory

# ls
auto_online_blocks  memory18  memory41  memory53  memory65  memory77
block_size_bytes    memory2   memory42  memory54  memory66  memory78
hard_offline_page   memory3   memory43  memory55  memory67  memory79
memory0             memory32  memory44  memory56  memory68  memory8
memory1             memory33  memory45  memory57  memory69  memory9
memory10            memory34  memory46  memory58  memory7   power
memory11            memory35  memory47  memory59  memory70  probe
memory12            memory36  memory48  memory6   memory71  soft_offline_page
memory13            memory37  memory49  memory60  memory72  uevent
memory14            memory38  memory5   memory61  memory73
memory15            memory39  memory50  memory62  memory74
memory16            memory4   memory51  memory63  memory75
memory17            memory40  memory52  memory64  memory76

ここで80番目のメモリを認識させるには以下のように、そのメモリのブロック番号に対応する物理アドレスを指定します。block_size_bytesが128MiBの環境なので、128MiB*80=0x280000000の物理アドレスを指定します。

# echo 0x280000000 > probe <------ 80番目のブロックを認識させます。

# ls
auto_online_blocks  memory18  memory41  memory53  memory65  memory77
block_size_bytes    memory2   memory42  memory54  memory66  memory78
hard_offline_page   memory3   memory43  memory55  memory67  memory79
memory0             memory32  memory44  memory56  memory68  memory8
memory1             memory33  memory45  memory57  memory69  memory80 <--- 指定した領域のメモリが認識され、ディレクトリが追加された！
memory10            memory34  memory46  memory58  memory7   memory9
memory11            memory35  memory47  memory59  memory70  power
memory12            memory36  memory48  memory6   memory71  probe
memory13            memory37  memory49  memory60  memory72  soft_offline_page
memory14            memory38  memory5   memory61  memory73  uevent
memory15            memory39  memory50  memory62  memory74
memory16            memory4   memory51  memory63  memory75
memory17            memory40  memory52  memory64  memory76

# cd memory80
# cat state
offline  <--- まだoffline状態のままですが、これは後で説明します

上記のようにmemory80のメモリブロックが認識され、ディレクトリが追加されました。このようにハード・ファームがメモリをhotaddで追加したときには、このメモリブロックのディレクトリが新たに追加されるという形になります。上記のprobeによる操作は、これをエミュレートするような動作というわけですね。

4.2 CXLでの操作

CXLではcxlコマンドによって、デバイスを認識させることができます。
なお、CXLコマンドのrepositoryは不揮発メモリの管理コマンドであるndctlと同じ場所 ( https://github.com/pmem/ndctl ) にあります。
また、コマンドの解説も( https://docs.pmem.io/ndctl-user-guide/cxl-man-pages/cxl-enable-memdev-1 )6とpmem.ioに置いてあり、不揮発メモリのときの開発者がそのままCXLの開発へ移行した名残がのこっています。

解説によるとCXLデバイスのデバイスの認識、取り外しは以下のコマンドで実行できるようです。

cxl enable-memdev <memory device>

cxl disable-memdev <memory device>

なお、CXLではデバイスを取り付けただけではだめで、仕様上regionやinterleaveなどの設定などを行う必要があります。interleaveの設定方法などについては、私もまだ勉強中なのですが、CXLではデバイスの認識のあとでonline操作の前に必要な設定や、offline後で取り外し前にも操作が必要なことがわかれば、とりあえずは充分です。
本記事ではregionの設定( https://manpages.ubuntu.com/manpages/lunar/man1/cxl-enable-region.1.html )についてだけ示しておきます。

cxl enable-region <region> [<options>]

cxl disable-region <region> [<options>]

また、筆者はまだ試していないのですが、QEMUによるCXLエミュレーションの開発も盛んに行なわれています。以下の手順でCXLのエミュレーション環境を試すことができるようなので、興味の有る人は挑戦してみてください。

4.3 QEMUでの操作

QEMUでもmemory hotplugについてドキュメントが書かれており、この配下のゲストへのmemory hotplugの操作ができるようです。こちらも参考になるでしょう。
https://github.com/qemu/qemu/blob/master/docs/memory-hotplug.txt

5. aとbの動作の連動について

5.1 aとbとの連動とは

現在のmemory hotplugのデフォルトの動作では、aのハードウェアの認識後、自動的にb.すなわちkernelがonlineするようになっています。しかし、かつては自動ではなく一旦kernelからユーザランドのエージェントに通知して、エージェント側からonlineするような動作になっていました。そうすると、そもそもなぜこのような2段階に分かれていたのでしょうか？

正直言うと、なぜこうなったか？という点については私もだいぶ記憶から薄れているのですが、理由の一つとして以下のようなものがあったと記憶しています。

世の中には、メモリだけでなく、次の図のように複数のCPUとDIMMが複数刺さったマザーボードのような基盤がまるごとhotplugできるケースがあります。

SB_hotplug.png

一般的に、hotplugされたデバイスに対してudevと呼ばれる仕組みでユーザランドのエージェントなどが起動し、hotplugされたデバイスを識別して特定のデバイス名をつけたりすることに使われています。

udevについてはdebianの解説などが参考になるので、そちらをご覧ください。

このように、基盤ごとhotplugされる場合、例えばhotaddの動作は以下のようになります。

  1. aの動作として、ドライバ経由で基板上のCPUとメモリがすべて認識される。
  2. ホットプラグされる単位として、その基盤まるごと１つがhotplug eventとしてudev経由で通知される。（この通知はCPUやメモリごとではなく、基盤丸ごと１つの通知となる)
  3. ユーザー空間のエージェントが通知に応じて動作する。エージェントは基板上に載っているCPUsやメモリブロックを判別する。
  4. 判別した基板上のCPU群とメモリブロックを、エージェントがすべてonlineにする。

SB_hotplug2.png

このように、hotplugされるデバイス構成が複雑な場合、ユーザー空間で動作するエージェントからデバイス自身やその内部の構成を認識したうえで、システムに組み込む方が都合が良いというケースがあるわけです。
このため、memory hotplugが初めて開発されたときは、初期状態のメモリブロックはofflineとなっており、エージェントやベンダーが提供するコマンドからオンライン化するのがデフォルトとなっていました。

しかし、私がmemory hotplugの開発から離れた後、他にもmemory hotplugのユーザが増えるにつけ、a.のあとにb.がudev経由で行なわれなければならないというのは、「難しい」と言われるようになったようです。このため、現在ではa.のメモリの認識のあと直接b.のonline操作が連続で行なわれるのがデフォルトの動作となっています。

5.2 自動でonlineしたときのデフォルトのZONEの指定

このようにデフォルトでは、上記のようにメモリデバイスの認識後すぐにonlineするようになったので、sysfsからstateへの入力が不要となりましたが、逆にZONE_MOVABLEにするかそれ以外の領域にするかどうかを決めるチャンスがなくなってしまいました。このため、memhp_default_stateというkernelのbootオプションで、onlineしたときのデフォルトのZONEを決めることが出来るようになりました。

memhp_default_stateには以下の値を指定することができます。online_movableを指定すると、a.の操作でメモリが接続されると、そのままZONE_MOVABLEの領域としてb.のonline化の動作がkernel側で行われます。

 memhp_default_state=online/offline/online_kernel/online_movable

4.1節ではこの値をofflineに指定しましたが、こうするとa.の動作の後は一旦offlineで待機する動作となります。なので、probeした直後の80番のメモリブロックは連動してonlineの動作をせず、offlineのままだったということです。あとからエージェント経由で動作させたいという場合は、この設定が役に立つでしょう。今後CXLによるリソースプールが実現されるときも、もしかすると役に立つかもしれません。

また、この値は、以下のsysfsのファイルでも変えることが出来ます。どう変わるか実験してみましょう。

# pwd
/sys/devices/system/memory
# cat auto_online_blocks 
offline
# echo online_movable > auto_online_blocks 
# cat auto_online_blocks 
online_movable <------------------ 設定値が変わりました
# echo 0x288000000 > probe <------ 81番目のブロックを認識させます。
# cat memory81/state  
online   <------------------------ 81番めのブロックが一気にonlineにされたことがわかります。
root@racailum:/sys/devices/system/memory# cat memory81/valid_zones 
Movable  <------------------------ ZONE_MOVABLEとしてonlineされたことがわかります。

このように、sysfsの設定でもauto onlineの動作を変えることができます。

6. まとめ

メモリホットプラグの操作方法について最も重要な点を述べてきました。
ほかにも細かい話は色々あるのですが、ここまでの説明でもかなり長くなってしまったので、それについて興味のある方はkernelのソースコード内にある

なども参照してください。

それでは良いお年を！

  1. メモリプールとはあるサーバーのメモリを抜いて、他のサーバにメモリを追加するような仕組みです。つけ外しの際にOSをshutdownさせておくのが確実ですが、片方のサーバーからmemory hotremoveの機能でメモリを削除して、そのメモリを他のサーバにmemory hotaddすることで、shutdownに伴うダウンタイムなしに資源の移動が可能となります。 ↩

  2. 私が開発に着手したのは2003年頃なので、それを含めるともう20年経過したわけですね…。 ↩

  3. 当時のkernel内のデータ構造の問題や、それをどう克服したかの技術的な内容については、こちらの記事のほうがくわしいです。 ↩

  4. 搭載メモリが20GiBのはずなのに20GiB以上の物理アドレスがあることに不思議に思う人がいるかもしれません。しかし、x86-64のアーキでは物理アドレスの途中に、メモリではなくデバイスのために割り当てられている領域があったりします。そういう領域をスキップしてメモリのアドレスが割り当てられるため、物理アドレスとしては20GiBより少しはみ出たところまでが割り当てられます。実際このマシンでは21.5GiBぐらいまでが物理アドレスとして割り当てられていました。このような物理アドレスのマップ情報はdmesg中に出力されています。 ↩

  5. 一部のエンタープライズ向けサーバにはDDR DRAMのメモリの一部をmirroringして冗長化することができるものがあるのですが、その領域をkernelが使えるようにし、それ以外の領域をZONE_MOVABLEにしてhotplug可能にするための指定です。（その場合、kernelはファームウェアからmirrorされた範囲をファームウェア、より正確にはEFI経由で教えてもらうことになります）。 ↩

  6. 2023/12/16日現在は、ちょっと記載が変になっていますね…。 ↩

40
27
3

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
40
27

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?