Linuxカーネルのメモリ管理とは？ページフレーム・メモリゾーン・Buddy Allocator・SLUBをわかりやすく解説

はじめに

Linuxでは、多数のプロセスやカーネルが同時に動作しながら、限られた物理メモリ（RAM）を効率よく共有しています。

しかし、物理メモリは単純に「空いている領域を使う」という仕組みではありません。Linuxカーネルは、ページ単位で物理メモリを管理し、用途に応じてメモリを分類したうえで、高速に割り当て・解放を行うためのさまざまな仕組みを備えています。

例えば、

• Linuxカーネルは物理メモリをどのように管理しているのか
• Buddy Allocatorはどのようにメモリを割り当てるのか
• Slab Allocatorは何のために存在するのか
• kmalloc()とvmalloc()はどのように使い分けられるのか

といった疑問は、Linuxカーネルのメモリ管理の仕組みを理解することで説明できるようになります。

また、商用システムでは、メモリ不足やカーネルメモリの異常を調査するために、/proc/buddyinfo、/proc/slabinfo、/proc/zoneinfo、slabtopなどを確認する場面があります。これらの情報を正しく読み取るためにも、カーネル内部でメモリがどのように管理されているのかを理解しておくことは重要です。

本記事では、Linuxカーネルによる物理メモリ管理の全体像を説明したうえで、ページフレーム、メモリゾーン、Buddy Allocator、Slab Allocatorの仕組みを分かりやすく解説します。

Linuxカーネルのメモリ管理とは

Linuxカーネルでは、プロセスごとに独立した仮想アドレス空間が割り当てられています。しかし、プロセスが利用するメモリは、実際にはLinuxカーネルによって管理されている物理メモリ（RAM）の一部です。

例えば、アプリケーションが malloc() や new を使用してメモリを確保すると、その要求に応じて仮想アドレス空間上に利用可能なメモリが割り当てられます。しかし、その裏側では、Linuxカーネルが物理メモリを管理し、必要に応じてページを割り当てています。

つまり、アプリケーションが直接物理メモリを操作しているわけではありません。Linuxカーネルが仲介役となり、物理メモリの割り当てや解放、再利用を管理することで、多数のプロセスが安全かつ効率的にメモリを利用できるようになっています。

Linuxにおけるメモリ管理の全体像を図で表すと、以下のようになります。

Linuxカーネルは、物理メモリ全体をページ（Page）と呼ばれる一定サイズの単位（一般的には4KB）で管理しています。さらに、用途やサイズに応じて複数の仕組みを組み合わせることで、高速かつ効率的なメモリ管理を実現しています。

代表的な仕組みは次のとおりです。

• ページフレーム（Page Frame）：物理メモリをページ単位で管理する
• メモリゾーン（Memory Zone）：用途に応じて物理メモリを分類する
• Buddy Allocator：ページ単位で物理メモリを割り当て・解放する
• Slab Allocator（SLUB）：カーネルオブジェクトを効率よく管理する

これらはそれぞれ異なる役割を持っていますが、連携することで高速かつ効率的なメモリ管理を実現しています。

次章からは、それぞれの仕組みについて詳しく見ていきましょう。

ページフレームとは

Linuxカーネルは、物理メモリ（RAM）全体をページ（Page）と呼ばれる一定サイズの単位に分割して管理しています。一般的なx86_64環境では、1ページのサイズは4KBです。

例えば、16KBのメモリ領域を確保する場合でも、Linuxカーネルは1バイト単位ではなく、4KB単位でページを割り当てます。そのため、16KBのメモリは4ページ分として管理されます。

物理メモリをページ単位で管理することで、メモリの割り当てや解放を効率的に行えるだけでなく、仮想メモリとの対応付けもしやすくなります。

物理メモリのイメージを図で表すと、以下のようになります。

Linuxカーネルでは、この物理メモリ上の各ページをページフレーム（Page Frame）として管理しています。

厳密には、「ページ」はメモリを一定サイズに分割した単位を表す一般的な用語であり、「ページフレーム」は物理メモリ上に存在するページを指します。

例えば、プロセスが malloc() によってメモリを確保すると、Linuxカーネルは空いているページフレームを割り当て、MMUがそのページフレームを仮想アドレスへ対応付けます。

つまり、プロセスは仮想アドレスを利用していますが、その裏側ではページフレームが実際のデータを保持しています。

さらに、Linuxカーネルは各ページフレームについて、次のような情報を管理しています。

• 使用中か空きか
• どのプロセスが利用しているか
• ページキャッシュとして利用されているか
• Dirty Page （※）かどうか
• 参照回数（Reference Count）

これらの情報は、カーネル内部で struct page というデータ構造によって管理されています。

※Dirty Pageとは、メモリ上で更新されたものの、まだディスクへ書き戻されていないページです。一定時間後やメモリ不足時に、Linuxカーネルがディスクへ書き込みます（Writeback）。

struct page

Linuxカーネルでは、すべてのページフレームに対してstruct pageが1つずつ対応しています。

struct pageには、ページフレームそのもののデータを保存しているわけではありません。代わりに、そのページフレームの状態や管理情報が格納されています。

struct pageは物理メモリ上に存在するページそのものではなく、Linuxカーネルが保持する管理用データ構造です。各ページフレームに対して1つずつ対応しており、ページの状態を管理しています。

例えば、以下のようなイメージです。

Buddy Allocatorは、このstruct pageの情報を参照しながら、「どのページフレームが空いているか」「どのページフレームを割り当てられるか」を判断しています。

そのため、ページフレームはLinuxカーネルのメモリ管理における最も基本的な管理単位といえます。

メモリゾーン（Memory Zone）

Linuxカーネルは、物理メモリをページ単位で管理しています。しかし、すべてのページが同じ用途で利用できるわけではありません。

例えば、一部のデバイスは物理メモリの低いアドレスしかアクセスできなかったり、カーネルが優先的に利用したい領域があったりします。そのため、Linuxカーネルは物理メモリを用途ごとに複数の領域へ分類して管理しています。この分類をメモリゾーン（Memory Zone）と呼びます。

メモリゾーンのイメージを図で表すと、以下のようになります。

Linuxカーネルは、ページフレームごとに「どのメモリゾーンに属しているか」を管理しており、用途に応じて適切なゾーンからページを割り当てます。

代表的なメモリゾーンには、次のようなものがあります。

それぞれについて詳しく見ていきます。

DMAゾーン

DMA（Direct Memory Access）は、CPUを介さずにデバイスが物理メモリへ直接アクセスするための仕組みです。

古いデバイスの中には、物理メモリ全体へアクセスできず、低位アドレスのメモリしか利用できないものがあります。

そのため、LinuxではDMA専用の低位メモリ領域を確保し、この領域をDMAゾーンとして管理しています。

現在の64bitサーバではDMAゾーンを意識する場面は多くありませんが、互換性のため現在でも残されています。

DMA32ゾーン

DMA32ゾーンは、32bitアドレスしか扱えないDMAデバイス向けのメモリ領域です。

例えば、一部のPCIデバイスでは、4GBを超える物理アドレスへアクセスできません。
そのため、このようなデバイス向けに4GB未満の物理メモリをDMA32ゾーンとして管理しています。

一般的なアプリケーションでは、このゾーンを意識することはほとんどありません。

Normalゾーン

Normalゾーンは、Linuxカーネルが最も頻繁に利用するメモリ領域です。

カーネルオブジェクトやページキャッシュ、各種バッファなど、多くのメモリはこのNormalゾーンから確保されます。

そのため、Buddy Allocatorがページを割り当てる際も、通常はNormalゾーンを対象に動作します。
64bit環境では、実質的にこのNormalゾーンがメインの物理メモリ領域となります。

HighMemゾーン

HighMemは、32bit Linuxで利用される特殊なメモリ領域です。

32bit環境では、カーネルが直接アクセスできる物理メモリ量に制限があり、それを超えるメモリはHighMemとして管理されます。

HighMemを利用する際は、一時的にカーネルの仮想アドレス空間へマッピングする必要があり、Normalゾーンよりアクセスコストが高くなります。

一方、64bit Linuxでは広大な仮想アドレス空間を利用できるため、この制限がありません。そのため、現在の64bit環境ではHighMemは通常利用されません。

メモリゾーンまとめ

現在の商用サーバの多くは64bit Linuxを採用しています。

そのため、実際の運用で主に利用されるメモリゾーンは、Normalゾーンです。DMAやDMA32は一部のハードウェアとの互換性のために存在し、HighMemは64bit環境では基本的に利用されません。

このように、Linuxカーネルは物理メモリを用途ごとに分類することで、ハードウェアの制約へ対応しながら効率的なメモリ管理を実現しています。

次章では、このメモリゾーン内のページフレームをどのように割り当て・解放しているのかを、Buddy Allocatorの仕組みを通して見ていきます。

Buddy Allocator

Buddy Allocator（バディアロケータ）は、Linuxカーネルが物理メモリ（ページフレーム）を効率的に割り当て・解放するためのメモリアロケータです。

前章で説明したように、Linuxカーネルは物理メモリをページ単位で管理しています。しかし、ページを単純に1ページずつ管理しているだけでは、大きなメモリ領域を効率よく確保したり、解放したメモリを再利用したりすることが難しくなります。

そこでLinuxでは、Buddy Allocatorを利用して、2のべき乗単位でページを管理しています。

例えば、4KBページを基準とすると、Buddy Allocatorは次のようなサイズでメモリを管理します。

つまり、16KBのメモリが必要な場合は、4KBページを4枚まとめたOrder 2のページブロックが割り当てられます。

このように、ページを複数まとめて管理することで、さまざまなサイズのメモリ要求へ柔軟に対応できるようになっています。

Buddy Allocatorの仕組み

Buddy Allocatorは、物理メモリを2のべき乗サイズ（Order）のブロックとして管理しています。

メモリの割り当て要求があると、まず要求サイズを満たす最小のブロックを探します。もし該当するサイズの空きブロックが存在しない場合は、より大きなブロックを取得し、必要なサイズになるまで順番に分割していきます。

例えば、16KBのメモリが必要な場合、64KB（Order 4）のブロックしか空いていなければ、まず32KB（Order 3）へ分割し、さらに16KB（Order 2）へ分割します。そして、生成された16KBブロックの1つが要求元へ割り当てられ、残りのブロックは空きブロックとして保持されます。

一方、メモリを解放する際は、同じサイズのBuddy（相棒）となるブロックが空いているかを確認します。Buddyも空いていれば2つのブロックを結合し、より大きなブロックへ戻します。この結合処理は繰り返し行われるため、32KB、64KBと順次大きなブロックへ統合されることがあります。

このように、Buddy Allocatorは「割り当て時は必要なサイズまで分割し、解放時はBuddy同士を結合する」という仕組みにより、物理メモリを効率よく管理するとともに、断片化（フラグメンテーション）の発生を抑えています。

Slab Allocator（SLUB）

前章では、Buddy Allocatorがページ単位で物理メモリを管理する仕組みについて説明しました。

しかし、Linuxカーネルが扱うデータは、必ずしも4KB単位とは限りません。

例えば、プロセスを管理するtask_structや、ファイル情報を管理するinode、ディレクトリエントリを管理するdentry、ネットワーク通信で利用されるsk_buffなど、多くのカーネルオブジェクトは数十～数百バイト程度のサイズです。

もし、このような小さなオブジェクトを確保するたびにBuddy Allocatorから4KBページを取得していたら、ページ内の大部分が未使用となり、多くのメモリが無駄になってしまいます。

そこでLinuxカーネルでは、小さなオブジェクトを効率よく管理するために、Slab Allocatorを利用しています。

なお、現在のLinuxでは、従来のSlab Allocatorを改良したSLUB Allocatorが標準のメモリアロケータとして採用されています。本記事では一般的な名称である「Slab Allocator」を用いながら、実際の実装はSLUBであることを前提に説明します。

Buddy Allocatorとの違い

Buddy AllocatorとSlab Allocatorは、それぞれ役割が異なります。

Buddy Allocatorはページ単位で物理メモリを管理する仕組みです。一方、Slab AllocatorはBuddy Allocatorから取得したページを利用し、小さなオブジェクトを効率よく管理します。

つまり、両者は競合する仕組みではなく、それぞれ異なる役割を担いながら連携して動作しています。

Slab Allocatorの仕組み

Slab Allocatorは、Buddy Allocatorからページを取得し、そのページを同じ種類・同じサイズのオブジェクトに分割して利用します。

例えば、task_structを管理する場合は、取得した1ページを複数のtask_structへ分割して格納します。

このように1ページへ複数のオブジェクトを配置することで、メモリを無駄なく利用できます。

※ task_structは、Linuxカーネルがプロセスを管理するためのデータ構造です。

Linuxでは、プロセスが1つ起動するたびに、対応するtask_structが1つ作成されます。この構造体には、そのプロセスを管理するために必要な情報がまとめられています。

オブジェクトを再利用する

Slab Allocatorの大きな特徴は、一度確保したオブジェクトを再利用することです。

毎回Buddy Allocatorから新しいページを取得するのではなく、既に確保済みのオブジェクトを再利用することで、メモリ確保を高速に行えます。

オブジェクトごとにキャッシュを持つ

Slab Allocatorでは、オブジェクトの種類ごとに専用のキャッシュ（Slab Cache）を持っています。

代表的なキャッシュには次のようなものがあります。

同じ種類のオブジェクトは同じキャッシュから割り当てられるため、初期化済みのオブジェクトを効率よく再利用できます。

kmalloc()とvmalloc()

Linuxカーネルでは、動的にメモリを確保するための代表的な関数としてkmalloc() と vmalloc()が用意されています。

どちらもカーネルメモリを確保するための関数ですが、メモリの確保方法や用途が異なります。

kmalloc()

kmalloc()は、物理的にも連続したメモリを確保するための関数です。

例えば、128バイトのメモリを確保する場合は、次のように呼び出します。

void *buf = kmalloc(128, GFP_KERNEL);

kmalloc()が呼び出されると、まずSLUB Allocatorのキャッシュから空きオブジェクトを探します。

キャッシュに空きがあれば、そのオブジェクトを返します。

一方、空きがない場合はBuddy Allocatorから新しいページを取得し、SLUBのキャッシュへ追加した後にメモリを割り当てます。

このように、kmalloc()はBuddy AllocatorとSLUB Allocatorが連携して動作しています。

kmalloc()で確保されたメモリは、仮想アドレス上だけでなく、物理メモリ上でも連続しています。そのため、DMA（Direct Memory Access）を利用するデバイスドライバなど、物理的な連続領域が必要な場面で利用されます。

vmalloc()

vmalloc()は、仮想アドレス空間上で連続したメモリを確保するための関数です。

例えば、以下のように呼び出します。

void *buf = vmalloc(1024 * 1024);

vmalloc()では、物理メモリが連続している必要はありません。

例えば、物理メモリ上では次のように離れたページを利用できます。

Page 5
Page 18
Page 102
Page 230

これらをページテーブルによって連続した仮想アドレスへマッピングすることで、カーネルからは連続した仮想アドレスとして利用できます。

そのため、大きなメモリ領域を確保しやすいという特徴があります。

ただし、ページテーブルを介してアクセスするため、kmalloc()より若干オーバーヘッドがあります。

kmalloc()とvmalloc()の違い

kmalloc()とvmalloc()の違いは以下となります。

メモリ確保の流れ

ここまで、Linuxカーネルのメモリ管理を構成する各要素について説明してきました。

最後に、カーネルがメモリを確保する流れを説明します。ここでは、kmalloc()によって128バイトのメモリを確保する場合を例に説明します。

① kmalloc()が呼び出される

カーネルやデバイスドライバは、動的にメモリを確保する際にkmalloc()を呼び出します。

例えば、128バイトのメモリを確保する場合は、次のように記述します。

void *buf = kmalloc(128, GFP_KERNEL);

kmalloc()が呼び出されると、SLUB Allocatorによるメモリ割り当て処理が開始されます。

② SLUB AllocatorがSlab Cacheを確認する

kmalloc()が呼び出されると、SLUB Allocatorはまず対応するSlab Cacheを確認します。

今回の例では、kmalloc-128キャッシュが対象になります。

キャッシュ内に空きオブジェクトがあれば、それをそのまま返します。

空きがあれば、この時点でメモリ確保は完了します。

③ 空きがなければBuddy Allocatorへ要求する

Slab Cacheに空きがない場合は、新しいページが必要になります。

SLUB AllocatorはBuddy Allocatorへページの割り当てを要求します。

④ Buddy Allocatorがページを割り当てる

Buddy Allocatorは、メモリゾーン内の空きページを検索します。

要求サイズに応じて必要なOrderのページを探し、存在しなければ大きなページブロックを分割してページを生成します。

その後、取得したページをSLUB Allocatorへ返します。

⑤ SLUB Allocatorがページを分割する

Buddy Allocatorから受け取ったページは、そのまま利用されるわけではありません。

SLUB Allocatorはページを同じサイズのオブジェクトへ分割し、Slab Cacheへ登録します。

例えば、128バイトのオブジェクトを管理するキャッシュであれば、1ページの中に複数の128バイトオブジェクトを配置します。

その中から1つの空きオブジェクトが呼び出し元へ返されます。

⑥ オブジェクトを再利用する

確保したオブジェクトが不要になると、SLUB Allocatorへ返却されます。

ただし、この時点ではBuddy Allocatorへページは返却されません。

オブジェクトだけがSlab Cacheへ戻され、次回以降のメモリ確保で再利用されます。

そのため、多くの場合はBuddy Allocatorへアクセスすることなく、高速にメモリを確保できます。

ページ内のオブジェクトがすべて不要になった場合には、SLUB AllocatorはページをBuddy Allocatorへ返却します。

Buddy Allocatorは必要に応じてBuddy同士を結合し、大きなページブロックとして再利用します。

障害調査で見るポイント

Linuxでは、カーネルのメモリ管理状況を確認するために、さまざまな情報が/proc 配下で公開されています。

例えば、物理メモリ不足やカーネルメモリリーク、ページ割り当て失敗などの障害調査では、Buddy AllocatorやSLUB Allocatorの利用状況を確認することで原因を特定できる場合があります。

ここでは、代表的な確認方法を紹介します。

Buddy Allocatorの利用状況を確認する

Buddy Allocatorの空きページ数は、/proc/buddyinfoで確認できます。

[root@almalinux ~]# cat /proc/buddyinfo
Node 0, zone      DMA      2      1      2      3      2      1      2      1      1      0      3
Node 0, zone    DMA32   4076   3308   2707   1819   1355    842    501    293    131      6    241
Node 0, zone   Normal   1777   2289   7028   3472   1095    146     31     12      3      0      0
[root@almalinux ~]#

このファイルでは、各メモリゾーンごとのOrder別の空きページ数を確認できます。

特に、高いOrder（大きな連続ページ）の空きが極端に少ない場合は、メモリの断片化が進んでいる可能性があります。

SLUB Allocatorの利用状況を確認する

SLUB Allocatorの利用状況は、slabtopコマンドで確認できます。

[root@almalinux ~]# slabtop -o
 Active / Total Objects (% used)    : 257260 / 283100 (90.9%)
 Active / Total Slabs (% used)      : 8675 / 8675 (100.0%)
 Active / Total Caches (% used)     : 164 / 232 (70.7%)
 Active / Total Size (% used)       : 55745.31K / 61446.80K (90.7%)
 Minimum / Average / Maximum Object : 0.01K / 0.22K / 8.00K

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
 39921  39856  99%    0.19K   1901       21      7604K kmalloc-192
 23296  16267  69%    0.03K    182      128       728K lsm_inode_cache
 22272  22131  99%    0.12K    696       32      2784K kernfs_node_cache
 19299  16426  85%    0.19K    919       21      3676K dentry
 14484  13927  96%    0.04K    142      102       568K vma_lock
 14220  13717  96%    0.21K    790       18      3160K vm_area_struct
 13440  12909  96%    0.66K    560       24      8960K inode_cache
  9906   9784  98%    0.10K    254       39      1016K buffer_head
  8576   8199  95%    0.06K    134       64       536K anon_vma_chain
  7392   7073  95%    0.07K    132       56       528K vmap_area

上記の通り、各Slab Cacheの使用量やオブジェクト数が表示されます。

代表的なSlab Cacheは以下となります。

・dentry
・inode_cache
・vm_area_struct
・kmalloc-192

特定のキャッシュだけが異常に増え続けている場合は、カーネルメモリリークを疑う手掛かりになります。

Slab Cacheの詳細を確認する

各Slab Cacheの詳細情報は、/proc/slabinfoで確認できます。

[root@almalinux ~]# cat /proc/slabinfo
slabinfo - version: 2.1
# name            <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>
nf_conntrack_expect      0      0    232   17    1 : tunables    0    0    0 : slabdata      0      0      0
nf_conntrack         208    208    256   16    1 : tunables    0    0    0 : slabdata     13     13      0
nf-frags               0      0    200   20    1 : tunables    0    0    0 : slabdata      0      0      0
fuse_request           0      0    152   26    1 : tunables    0    0    0 : slabdata      0      0      0
fuse_inode             0      0    896   18    4 : tunables    0    0    0 : slabdata      0      0      0
ext4_groupinfo_4k   1628   1628    184   22    1 : tunables    0    0    0 : slabdata     74     74      0
ext4_fc_dentry_update      0      0    104   39    1 : tunables    0    0    0 : slabdata      0      0      0
ext4_inode_cache     818   2314   1216   26    8 : tunables    0    0    0 : slabdata     89     89      0
ext4_free_data       803   1095     56   73    1 : tunables    0    0    0 : slabdata     15     15      0
ext4_allocation_context    120    120    136   30    1 : tunables    0    0    0 : slabdata      4      4      0
ext4_prealloc_space    144    144    112   36    1 : tunables    0    0    0 : slabdata      4      4      0
ext4_system_zone     306    306     40  102    1 : tunables    0    0    0 : slabdata      3      3      0
ext4_io_end_vec     1024   1536     32  128    1 : tunables    0    0    0 : slabdata     12     12      0

/proc/slabinfo では以下の情報を確認できます。

• キャッシュ名
• オブジェクト数
• オブジェクトサイズ
• 利用中・空きオブジェクト数

slabtopより詳細な情報を取得したい場合に利用します。

障害調査で特に確認したいポイントまとめ

障害調査では、次の点を確認すると原因を切り分けやすくなります。

これらの情報を組み合わせて確認することで、物理メモリ不足だけでなく、断片化やカーネルメモリリークなど、より詳細な原因を調査できます。

まとめ

Linuxカーネルは、限られた物理メモリ（RAM）を効率よく利用するために、複数の仕組みを組み合わせてメモリを管理しています。

本記事では、Linuxカーネルのメモリ管理の全体像を紹介し、ページフレーム、メモリゾーン、Buddy Allocator、Slab Allocator（SLUB）、そしてkmalloc()とvmalloc()の役割について解説しました。

それぞれの役割を整理すると、以下のようになります。

また、障害調査では、/proc/buddyinfo、slabtop、/proc/slabinfoなどを確認することで、物理メモリの断片化やSLUBキャッシュの利用状況、カーネルメモリリークの兆候を把握できます。これらのコマンドの役割を理解しておくことで、メモリ関連のトラブルをより効率的に調査できるようになります。

メモリ管理の詳細については、以下の通り詳細を記載していますので、合わせて読んでみてください。