日本ソフトウェア科学会第 36 回大会 (2019 年度) 講演論文集

リソース消費量に着目した Linux Kernel の分析
雫石 卓耶

松原 克弥

汎用性の高い OSS ライブラリや OS の普及にともなって，それらを組み合わせるシステム開発手法が一般的になっている．これにより，開発効率が大幅に向上するという利点がある一方，必要のない機能もシステムに組み込まれてしまうという課題がある．そのため，汎用的なソフトウェアから，必要な機能だけを効率的に取り出す最適化技
術が求められている．
本研究では，組み込み機器での活用も拡がっている Linux を対象として，その最適化を支援する手法を提案する．Linux の Kernel Config 機構を用いることで，システムに必要のない機能を無効にできる．しかし，その設定項目が約 10,000 個もあるため，最適な設定を手動で見つけることは困難である．本提案手法では，Linux の各機能
が，システムのメモリ使用量と電力消費量に与える影響を自動的に計測した．これにより，約 10,000 個の設定項目のうち，最適化に有効と思われるもののみに着目できる．

Reusable libraries and rich functional OSes have been greatly improving system development in terms oftime-to-market and product quality. On the other hand, such the general-purpose software must have codeand data which could be useless for the target system. Therefore, an optimization mechanism to eﬃciently
extract only the necessary and suﬃcient functions from the whole software code must be important.
This study aims to support to optimize Linux, which is the most used OS in various systems, including
embedded devices. Especially, embedded devices may require it because of limited computing resources
and costs. The Linux Kernel Config allows you to remove unnecessary functions explicitly in system building. Nevertheless, it must hard to specify an optimal configuration setting manually for each target systembecause there are about 10,000 selectable items in the Linux kernel config. We propose a method to automatically estimate the influence on the memory usage and power consumption of each kernel config itemin the target system. And an experimental result shows possible to automatically specify items that could
eﬀectively shrink resource usage for a target system.

アは，様々なユースケースに対応できるよう設計され

1 はじめにているため，特定のユースケースでは必要のない機

汎用的なソフトウェアから，必要な機能だけを取能も含まれている．そのため，汎用的なソフトウェア

り出す技術の必要性が高まっている．汎用性の高いを使用することで，不要な機能もシステムに組み込

OSS ライブラリや OS の普及にともなって，それら

まれてしまうという課題がある．不要な機能は，シスを組み合わせるシステム開発手法が一般化している．

テムのリソースを浪費してしまう．したがって，汎用汎用的なソフトウェアを使用することで，様々な機能的なソフトウェアから，必要十分な機能を取り出す必の設計や実装を省略できるため，開発効率が大幅に向要がある．このことは，ソフトウェアの Tinification

上するという利点がある．一方，汎用的なソフトウェと呼ばれる．

A Method of Analysing the Linux Kernel Focusing
Resource Consumption
This is an unrefereed paper. Copyrights belong to
the Author(s).
Takuya Shizukuishi, Katsuya Matsubara, 公立はこだて未来大学, Future University Hakodate.

Tinification が求められているソフトウェアの 1 つに，Linux がある．デバイスドライバやネットワー
クスタックなどの，豊富なソフトウェア資産を持つLinux は，組み込み用途の OS としても広く活用されている [5]．一方，システムにとって不要な機能が，メモリ使用量や電力消費量を増大させてしまうという問を行った [3]．もう 1 つは，各設定項目がリソース消題がある．一般的に，組み込み機器には，メモリ使用費量へ与える影響を評価する手法である．著者らに量や電力消費量などの資源に制限がある．そのため，よる以前の研究 [3] では，計測値の分散による影響をLinux の Tinification が求められる．Linux には，そ排除できていないという課題があった．そのため，計の機能を取捨選択するための，Kernel Config という測結果の精度が低く，リソース消費量への影響が明確機構がある．そのため，この設定を調整することで，ではなかった．また，解析可能なリソース消費量が，システムのリソース消費量を削減できる．

メモリ使用量だけであるという課題もあった．

しかし，Kernel Config には，手動での調整が難し

本稿では，Kernel Config の設定項目ごとに，メモいという問題がある．Kernel Config を調整すること

リ使用量と電力消費量に与える影響を評価する手法

で，不要な機能を無効化できるが，次の 3 つの理由を提案する．各設定項目を無効にした Linux Kernelにより容易ではない．1 つ目の理由は，各設定項目のを実際に起動し，ユーザープロセスを動作させるこ

必要性を判断することが難しいということである．各とで，リソース消費量への影響を計測する．計測を複設定項目がシステムにとって必要な場合，その設定項数回行い，統計的検定手法を用いることで，リソース目を無効化してしまうと．システムが正常に動作しな消費量への影響が有意なものかを判定する．これにくなってしまう．各設定項目の必要性を判断するため

より，リソース消費量の分散による影響を最小限に抑には，Linux Kernel やユーザープロセスに関する深える．また，解析可能なリソース消費量に，電力消い知識が必要である．そのため，各設定項目の必要性

費量を追加することで，新たな視点での Tinification

は．容易に判断できない．2 つ目の理由は，各設定項を可能にする．

目がリソース消費量に与える影響を判断しにくいと以降，本稿の構成は，次のようになっている．第 2いうことである．設定項目の中には，無効にすること

章では，Linux における Kernel Configuration シス

で，リソース消費量を増加させてしまうものも存在す

テムの概念と仕組みについて述べる．第 3 章では，本る場合がある．そのため，設定項目を無効化すること

稿で提案する手法の詳細について述べる．第 4 章でで，メモリ使用量や電力消費量が，減少するのか，増は，提案手法の具体的な実装方法について述べる．第加するのか，または変化しないのかを判断する必要が5 章では，組み込み用途の Linux ディストリビューある．これは，設定項目を一見しただけでは判断できションである Tiny Core Linux の，Raspberry Pi 向

ない．3 つ目の理由は，Kernel Config の設定項目が，約 10,000 項目もあるということである †1 ．必要性のけパッケージである piCore を用いて，本手法の有用判断や，リソース消費量に与える影響の確認を，全て研究と関連する研究についてまとめ，本研究との類似の設定項目に対して，手動で行うことは困難である．

点や相違点について述べる．第 7 章では，本稿の結本研究では，各設定項目の必要性とリソース消費量性を検証するための評価結果を示す．第 6 章では，本論と今後の課題を述べる．

への影響を自動計測することで，Tinification 作業を支援することを目的とする．この計測結果により，約10,000 個の設定項目の中から，リソース消費量の削2 Linux における Kernel Configuration
システム

減に効果的な項目を優先的に着目して，Tinification

Kernel Config は，Linux Kernel のコンパイル時

作業を効率的に進められる．この目的を達成するために，その機能を取捨選択するための機構である．Linuxには，2 つの手法を確立する必要がある．1 つは，設のソースコードには，Kernel Config を設定するた

定項目の必要性を評価する手法である．この手法に関めの，nconfig などの様々なツールが含まれている．

しては，著者らが 2018 年に行った研究で提案と評価

nconfig の実行例を図 1 に示す．図 1 の各行は，設定†1 Linux Kernel v4.9.22 における設定項目のうち，設定画面に現れ得る（prompt 属性を持つ）項目数

項目またはメニューを表している．メニューは, 設定
項目の集まりである．メニューを展開することで，更config SCSI
tristate " scsi device support "depends on BLOCK
select SG_POOL...

図2

kconfig ファイルによる設定項目の定義例

ト，依存関係，逆依存関係を持つ場合がある．設定項目
は，Kernel ソースファイルの各所にある，Kconfig という名前のファイルによって定義されている．Kconfig
ファイルによる，設定項目の定義例を図 2 に示す．図図1

2 の「SCSI」は，設定項目の名前である．この名前は，nconfig の実行例

全設定項目の中で一意である．
「scsi device support」
表1

Config 項目の型と Linux Kernel v4.9.22 における項目数

は，プロンプトである．プロンプトは，nconfig などのツールの各行に表示される名前である．なお，設定項目の中には，プロンプトを持たず，nconfig に型設定できる値

項目数booly(有効) か n(無効)5237

Kernel Config の状態をわかりやすくするためのダtristatey(有効)，m(カーネルモジュー

7436

ミーとして，Kernel ソースコードの内部で使用されルとして有効)，n(無効) のい

表示されないものもある．そのような設定項目は，る．
「depends on BLOCK」は，依存関係を表していずれかる．この例では，SCSI が BLOCK という設定項目

hex

16 進数

39

の機能に依存していることを示している．そのため，

int

整数

228

BLOCK を有効にしなければ，SCSI を有効にできな

string

文字列

42

い．
「select SG POOL」は，逆依存関係を表してい

12982

る．逆依存関係を用いることで，他の設定項目を強制合計的に有効にできる．この例では，SCSI が有効なときに詳細な設定項目の値を変更できる．

に，SG POOL が強制的に有効になる．そのため，逆設定項目には，型と値がある．Kernel Config に依存関係によって，設定項目が「ロック」される場合

おける型と，それに設定可能な値，および，Linuxがある．例えば，図 1 の「Auditing support」は，他

Kernel v5.2.0 における各項目数を表 1 に示す．Ker-の設定項目の逆依存関係によって，値が「y」にロッ

nel Config における設定項目のほとんどが，bool かクされている．

tristate 型である．例として，図 1 の「uselib syscall」
や「Kernel .config support」が挙げられる．
「uselib

3 リソース消費量の自動計測手法

syscall」の行に，「*」記号が表示されている．これは，本手法では，各設定項目を無効にした Linux Kernel

その設定項目に，「y（有効）」が設定されていることを実際に起動し，ユーザープロセスを動作させる．こを示している．一方，「Kernel .config support」の行

れにより，各設定項目における，リソース消費量へのには，「*」記号が表示されていない．これは，その設影響を計測する．また，計測を複数回行い，統計的検定項目に「n（無効）」が設定されていることを示し

定手法を用いることで，リソース消費量への影響が有ている．

意なものかを判定する．

設定項目には，一意な名前がある．また，プロンプ

3. 1 計測対象とする設定項目

ソース消費量とデフォルト設定のリソース消費量の差

本節では，本手法が対象とする設定項目を定義す

分をとることで，各設定項目を無効にした際のリソーる．本手法が解析対象とする設定項目は，次のすべて

ス消費量の変化を計算し，これを各設定項目のリソーの条件を満たすものとする．

ス消費量とする．このとき，起動に失敗した Kernel

1. 設定項目の型が，bool か tristate であるbool や tristate 以外の型の設定項目は，対応する機能を無効化するための値が自明ではないた
め，解析の対象から除外する．

2. Tinification を実施する前の設定（以降，デフォ

は，その旨をログファイルに記録する．そして，この後の解析対象から除外する．
最後に，統計的検定手法を用いて，リソース消費量の削減に，統計的に有意な設定項目を判別する．上記の計測結果には分散がある可能性がある．そのため，

ルト設定）の値が，y か m である．

計測を何度か行い，平均をとることで，結果の精度を

Tinification 実施前から無効となっている設定項向上させる．また，デフォルト設定と各設定項目を無目はシステムの動作に必要ではないことが自明

効にした場合で，有意差の検定を行う．これにより，であるため，解析の対象から除外する．

各設定項目を無効にしたことによるリソース消費量

3. 設定項目が，prompt 属性を持っている．

の変化が，統計的な有意差であるかを判定する．

prompt 属性を持たない設定項目は，Kernel 利3. 2. 1 テストケース用者が設定するものではないため，解析の対象か

各 Kernel 上でユーザープロセスを動作させる際に，ら除外する．

4. 設定項目が，ロックされていない．

テストケースを実行することで，本番環境に近い状
態で計測を行う．本手法におけるテストケースとは，逆依存関係によってロックされている設定項目

システムが実際に取りうる動作のことである．例えは，値を変更できないため，解析の対象から除外

ば，組み込みアプリケーションのテストコードなどがする．

挙げられる．テストケースがとる動作のパターンは，できる限り多く，網羅的であるほうが望ましい．テス

3. 2 各設定項目のリソース消費量の計測方法

トケースの動作パターンが少ない場合，計測結果が本手法では，デフォルト設定の Linux Kernel と，汎用的なものとなってしまう．多くの動作パターンを各設定項目を無効にした Linux Kernel を起動，比較持つテストケースを動作させることで，より多くのすることで，各設定項目の必要性と，リソース消費量

Kernel の機能を使用して，計測作業を行える．そのに与える影響を計測する．

ため，よりシステムに特化した計測結果が得られる．

はじめに，デフォルト設定の Linux Kernel のリ

3. 2. 2 依存関係を考慮した設定項目の無効化

ソース消費量を計測する．そのために，デフォルト設

設定項目を無効化する際に，その他の設定項目を定の Linux Kernel を，コンパイルして起動し，ユー

無効化しなければならない場合がある．本手法では，

ザープロセスを実行する．ユーザープロセスの実行中

Kernel の設定項目を無効化することで，リソース消は，システムの CPU とメモリ，ネットワークの状態

費量の影響を計測する．ここで，ある設定項目を無効を記録する．実行が終了した後に，記録された情報か化する際，その設定項目に依存している有効な設定項

ら，テストケース実行直後のメモリ使用量と，テスト目を無効にする必要がある．依存関係の例を図 3 に

ケース実行中の電力消費量を算出する．

示す．図 3 の例 1 では，項目 A と B の間に依存関係

次に，各設定項目のリソース消費量を計測する．そがある．ここで，項目 B の機能は，項目 A の機能をのために，計測対象の設定項目それぞれについて，設用いて動作している．項目 A を無効化する場合，項定項目を無効にした Linux Kernel をコンパイルし，

目 B は動作できなくなるため，項目 B も無効化しな起動する．そして，デフォルト設定の Linux Kernel

ければならない．また，項目 B を無効化する際も同の場合と同様に，リソース消費量を算出する．このリ様の処理を行わなければならない．一方，例 2 では，

4. 2 統計的検定手法
config A(=y)

config A(=y)

config C(=y)

リソース消費量への影響が有意な設定項目を判別するために，対応のある 2 群の t 検定による両側検定

config B(=y)
depends on A

config B(=y)
depends on A || B

例1

例2

を行った．検定は，設定項目ごとの，メモリ使用量と電力消費量ごとに行った．例えば，設定項目 A を無効化することによる，メモリ使用量への影響を検定する場合は，次のような手順を行う．はじめに，デフォ：依存

ルト設定の Kernel と，検定対象の設定項目を無効にした Kernel それぞれのメモリ使用量を計測し，2 つ

図3

設定項目の依存関係の例の値を対標本とする．そして，計測の精度を高めるた
め，同様の計測を何度か行う．次に，帰無仮説を「2つの Kernel から計測されたメモリ使用量には，差がMemTotal :MemFree :MemAvailable :...

249188 kB
153084 kB
167976 kBない」と設定する．最後に，検定手法にしたがって t値を求め，それが棄却域に入るかを確かめる．帰無仮説が棄却された場合は，「2 つの Kernel から計測され

図4

meminfo ファイルの出力例

たメモリ使用量には，有意な差がある」と考えられる．この検定作業を，各設定項目の各リソース消費量

項目 B の機能は，項目 A か C が有効であれば動作すに対して行うことで，それぞれが有意な差なのかを判る．ここで項目 A を無効化する場合は，項目 B を無断できる．

効化する必要がない．なぜなら，項目 A を無効化し本実装では，検定を複数回行うため，検定の多重性ても，項目 C が有効なため，項目 B の機能は問題な問題に留意する必要がある．検定の多重性とは，「複く動作するからである．

数の検定の，どれかが有意であれば成り立つ，全体の仮説」を設定した場合に発生する問題である．この

4 実装

ような状況では，「全体の仮説が α エラーとなる確率」

4. 1 メモリ使用量と電力消費量の計測方法

が，「それぞれの検定が α エラーとなる確率」よりもメ モ リ 使 用 量 の 計 測 に は ，procfs の meminfo

大きくなってしまうという問題がある．しかし，本研

ファイ ル を 用 い た ．meminfo ファイ ル の 出 力 例 を

究では，複数の検定に関する仮説を設定していない．

図 4 に 示 す．MemTotal は ，シ ス テ ム 全 体 の メ モ

各設定項目の有意性を，それぞれ独立した検定によっリ 量 で あ る ．MemAvailable は ，利 用 可 能 な メ モて評価しているだけである．したがって，本研究におリ 量（ 空 き メ モ リ 量 ）で あ る ．メ モ リ 使 用 量 は ，ける，検定の多重性の問題は無いと判断した．

M emT otal − M emAvailable として算出した値を
計測した．

5 評価

電力消費量の計測には，Fabian Kaup ら（2014）が仮のシステムで本手法を実行し，設定項目がリソー提案した電力モデル [1] を用いた．Kaup らは，procfs

ス消費量に与える影響を，適切に計測できるかを評から得られる情報だけをもとに，機器の電力消費量

価する．今回想定したシステムは，テストケースとしを算出する，電力モデルを提案した．この電力モデルて，lmbench によるベンチマークを実行するものでを用いることで，Raspberry Pi の電力消費量を，9.3

ある．lmbench は，汎用的な UNIX システムの機能％の誤差で算出できている．Kaup らの手法を用いるを網羅的に実行し，その性能を評価するためのソフト

ことで，電気的な計測が不要になるという利点が得らウェアである．そのため，特定の組み込み機器に特化れる．

したものではない．しかし本評価では，あえて汎用的表2想定したシステムの構成

ハードウェア構成

Raspberry Pi

Linux
ディストリビューション

piCore v9.0.3

Linux Kernel

v4.9.22

テストケース

表4

計測作業を行ったマシンの環境OS

Ubuntu 18.04.2 LTS

CPUIntel(R) Xeon(R) CPU E5-2697 v3 @2.60GHz 48 コア vCPU

メモリ

110GB vRAM

lmbench（OS サブセ
ット）

環境を表 4 に示す．消費電力を算出する際の電力モ
デルには，Fabian Kaup ら（2014）の Raspberry Pi

表3

評価に用いた QEMU の設定のモデル [1] を用いた．この電力モデルが想定している構成と，今回用いた QEMU の構成は異なるため，

アーキテクチャarm

モデルの互換性に留意する必要がある．電力消費量

マシン

versatilepbの計測に用いるのは，CPU 使用率とネットワーク通CPUarm1176

信量の値である．今回のテストケースではネットワー

メモリサイズ

256MB

ク通信を行っていないため，CPU の挙動にのみ留意

その他のオプション

nographic, no-reboot

すれば良い．今回 QEMU で用いた CPU アーキテク
チャは，Raspberry Pi のものと同じため，モデルになベンチマークソフトウェアをテストケースとして用は互換性があると判断した．各設定項目の計測作業いた．これにより，本手法がどのような Linux の機は，10 回行い，平均を計算した．その後，統計的検能に有効なのかを網羅的に評価する．

定手法によって，各設定項目のリソース消費量の変化を検定した．検定の有意水準は a = 0.05 とした．t5. 1 評価条件

分布の自由度は 9 である．そのため，t > 2.2622 の今回想定したシステムの構成を表 2 に示す．システ

とき，リソース消費量の変化が有意だと判断した．

ムは，Raspberry Pi 3 B に piCore v9.0.3 を導入し，テストケースとして lmbench を実行するものとした．

5. 2 評価結果

なお，lmbench の実行するベンチマークを，OS サ

本手法による，リソース消費量の計測結果の概要

ブセットに限定した．これにより，OS に関係の無いを表 5 に示す．各行は，各分類に該当する設定項目のベンチマークを実行しないことで，解析時間を短縮

数を示す．字下げが行われている分類名は，その 1 つ

した．

前の分類に属すことを示す．メモリ使用量，電力消費

計測時間を短縮するため，並列実行された仮想環

量ともに，それらを統計的に有意に増加・減少させる

境上で計測を行った．仮想化ハイパーバイザとして，設定項目があるという結果となった．また，解析には

QEMU v2.11.1 を用いた．評価に用いた QEMU の

33 時間を要した．

設定を表 3 に示す．QEMU マシンとして versatilepb

メモリ使用量への影響が有意であると判定された設を用いているのは，QEMU の Raspberry Pi 3 サポー

定項目の上位 20 件を表 6 に示す．1 行目はデフォル

トが完全でないため，Raspberry Pi と最も構成のト設定の Kernel による測定結果である．2 行目以降近いもので代用したからである．また，piCore をは，メモリ使用量への影響が有意な設定項目である．

versatilepb で動作させるために，Kernel Config を

2 列目の内容のうち，左に書かれている値は，デフォ

手動で調整した．

ルト設定の値との差を表している．つまり，各設定項

以上の条件でシステムを起動し，各設定項目のリ目を無効にすることで，メモリ使用量がどのようにソース消費量を計測した．計測作業を行ったマシンの変化したかを表している．例えば，TMPFS の行は，

表5

表6

リソース消費量の計測結果の概要

分類

設定項目数

メモリ使用量への影響が有意であると判定された設
定項目（t 値の絶対値で降順に整列した場合の上位 20 件）

解析対象の設定項目

1137├起動に失敗した

35

るメモリ使用量の変化└起動に成功した

1102(KB) と t 値

メモリ使用量の計測

1102

├減少した

360

│└有意差あり (p < 0.05)

116

├増加した

734

│└有意差あり (p < 0.05)

19

└変化なし

8

電力消費量の計測

1102

├減少した

742

│└有意差あり (p < 0.05)

18

└増加した

360

└有意差あり (p < 0.05)

3

設定項目名

デフォルト設定

設定項目の無効化によ

81971.20

TMPFS-47760.80(-1358.987)

SHMEM-47744.40(-1052.689)

SQUASHFS-20688.40(-740.983)

MISC FILESYSTEMS-21559.60(-732.651)

PROC SYSCTL-20836.00(-699.420)

SQUASHFS ZLIB

-20378.00(-602.324)

BLK DEV LOOP

-21622.80(-484.750)

FUTEX-20817.20(-483.668)

BLK DEV-23236.80(-391.937)

CFG80211-3908.80(-99.245)

WLAN-2543.60(-98.686)

その設定項目を無効化することで，メモリ使用量がFTRACE-4548.00(-98.149)

デフォルトのものから 47760.80KB 減少したことをNETDEVICES-4179.60(-88.384)

示している．2 列目の内容のうち，括弧の中に書かれ

NETFILTER-2819.20(-76.589)ているものは，各設定項目とデフォルト設定の差を検MODVERSIONS-2138.80(-57.093)

定した結果の t 値である．また，電力消費量への影

MAC80211-2193.60(-43.816)

響が有意であると判断された設定項目を表 7 に示す．

SOUND

-1319.60(-38.918)

表の形式の説明は，表 6 と同様である．

SND-1345.20(-36.194)

BTRFS FS

-1430.80(-35.643)

MD-1191.20(-34.501)

5. 3 考察表 5 において，メモリ使用量が増加した設定項目
は，減少したものよりも多かった．設定項目を無効に目，SND や SOUND などのオーディオ関係の項目，

することで，メモリ使用量が増加するのは，一見，予BTRFS FS などの使用していないファイルシステム

想と反する結果であるようにも思える．しかし，メモの項目などがある．これらの機能は，本評価のシス

リ使用量が有意に減少した項目と，有意に増加した項テムでは使用していない．そのため，本手法によっ目を比較すると，有意に減少した項目のほうが多いとて，システムに必要のない設定項目を判定できたと考わかる．そのため，前述した結果は，メモリ使用量へえる．

の影響が有意ではない項目によるものであるとわか

また，表 6 において，無効にすることでメモリ使る．計測値の誤差により，偶然このような結果が得ら

用量が約 47000KB も削減される設定項目があるこれたと考えることができる．

とがわかる．TMPFS や SHMEM を無効にすること

表 6 において，システムで必要とされていないで，デフォルト設定の半分以上のメモリ使用量を削

Kernel の 機 能 が 多 く 現 れ て い る と わ か る ．例 え

減可能であるという結果が出ている．メモリ使用量

ば，CFG80211 や WLAN などの無線 LAN 関係の項が大幅に減少した原因を調査するため，デフォルト

表7

電力消費量への影響が有意であると判定された設定
項目

表8

TMPFS を無効化した際の「/proc/meminfo」
ファイルの変化（t 値の絶対値の降順）

設定項目名

設定項目の無効化による電力消費量の変化

meminfo

TMPFS

TMPFS

無効化前

の項目

無効化前

無効化後

後の差

（KB）

（KB）

MemAvailable 167884

215608+477240-44912（KB）と t 値
デフォルト設定

669.09

Shmem

44912

VT

+164.36(7.676)

NLS CODEPAGE 1250

+19.22(5.709)

SCHED AUTOGROUP-39.19(-4.924)

FTRACE-39.25(-4.779)

BRIDGE EBT AMONG-28.87(-3.061)

SND SOC WM8731-22.67(-3.005)

IP VS LC

-18.24(-2.962)

FB TFT UPD161704-22.16(-2.754)

MEMCG-28.34(-2.753)

Kernel 上で df を実行した結果を図 5 に示す．rootfs

LEDS GPIO-41.27(-2.533)の使用容量が，initramfs の容量である．その容量は，

KEYBOARD GPIO

-49.44(-2.532)

減少した Shmem の容量とおおよそ一致する．した

IP PNP-12.30(-2.528)

がって，TMPFS を無効化することで，initramfs のDYNAMIC FTRACE+25.39(2.501)

容量が MemAvailable に含まれてしまうことが，メ

CIFS SMB2-20.14(-2.387)

モリ使用量が大幅に減少した要因である．initramfs

CAN BCM-30.80(-2.356)の容量が MemAvailable に含まれてしまう原因につ$ df
Filesystem ... Used ... Mounted on
rootfs... 43.9 M ... /図5

デフォルト設定の Kernel 上で df コマンドを実行
した結果

いては，さらなる調査が必要である．また，これらのINET6 XFRM
MODE TRANSPORT-34.83(-2.338)

設定項目が無効化された場合でも，initramfs 自体は

NLS CODEPAGE 857-43.33(-2.306)

メモリ上に存在しているため，この計測結果は誤りである．そのため，メモリ使用量の計測方法を見直す必NETFILTER XT

要がある．

TARGET NOTRACK-19.11(-2.304)

W1 SLAVE DS2431-16.07(-2.303)

さらに，表 6 において，SQUASHFS などの設定項

BATTERY DS2760-19.75(-2.293)

目を無効化することで，メモリ使用量が 20000KB もTASK IO ACCOUNTING-21.25(-2.263)

減少することがわかる．この原因として，piCore がパッケージ管理に squashfs を用いていることが考え設定の Kernel と，TMPFS を無効化した Kernel にられる．本評価で用いたシステムには，lmbench のおける「/proc/meminfo」ファイルを比較した．そコンパイル等に用いた piCore のパッケージが含まれの結果を表 8 に示す．表 8 を見ると，Shmem の容る．これらは，システムの起動時に，squashfs を用量が大きく減少し，MemAvailable が増加している．

いてメモリ上にマウントされることで，利用可能に

ここで，デフォルト設定の Kernel における Shmem

なる．しかし，SQUASHFS が無効となることで，マの容量の正体は，initramfs であると考えられる．なウントに失敗するため，メモリ使用量が減少したとぜなら，Shmem の実体は tmpfs であり，initramfs

思われる．これらのパッケージは，テストケースの実は，通常 tmpfs を用いてマウントされるためである．

行時には用いないため，システムの動作にとって不要

initramfs の容量を計測するため，デフォルト設定のである．そのため，SQUASHFS などの設定項目は，

無効にするべき項目である．

しかし，研究の目的が本研究とは異なる．Kurmus ら

表 7 を見ると，VT という設定項目を無効にするこの研究の目的は，Linux Kernel の攻撃面を排除するとで，電力消費量が有意に増加していることがわかる．

ために，Linux Kernel Tinificaion を行った．そのた

この設定項目は，疑似端末機能（tty など）を有効にめ，メモリ使用量や電力消費量といったリソース消費する設定項目である．この設定項目を無効にした状量に関しては考慮していない．本研究では，リソース態の，システムの挙動を確認したところ，getty がロ

消費量の削減を目的として，Linux の各機能がリソー

グインに何度も失敗していることがわかった．getty

ス消費量に与える影響を調査した．

は，疑似端末を制御するためのプログラムである．デフォルトの piCore では，起動時に getty が tty1 で自7 まとめ

動ログインするように設定されている．しかし，VT

本研究では，Kernel Config の設定項目がリソースを無効にすることで，tty そのものの機能が無効にな

消費量に与える影響の評価手法を提案した．これによるため，getty がログインに失敗する．getty はログ

り，多くの設定項目の中から，リソース消費量の削減

インに失敗すると，再度ログインを試みる挙動をするに効果のあるもののみに着目して，Tinification 作業

ため，無限にログインの失敗が起こり，CPU 資源なを行うことができるようになる．本手法では，各設定どを消費する．その結果，システムの電力消費量が増項目を無効にした Linux Kernel をコンパイルし，起加したと考える．

動することで，各設定項目のリソース消費量を計測

なお，本手法の実行には，約 33 時間を要した．このした．また，統計的検定手法を用いることで，リソー時間が長いかどうかは，Tinification 実行者の置かれス消費量が有意に変化する設定項目を判別した．さる環境に依存するため，一概には判断できない．しからに，組み込み用途の Linux ディストリビューショ

し，本手法は全て自動化されているため，Tinification

ンである piCore 上で lmbench を動作させることで，実行者への負担は少ないと考える．

本手法の有用性を評価した．その結果，リソース消費量を有意に低下させると思われる，いくつかの設定項

6 関連研究目を判別できた．

池田（2006）は，Kernel の機能と，Kernel イメー

今後，2 つの課題を解決する必要がある．1 つは，ジサイズやメモリ使用量の関係を調査した [4]．この研

テストケースの検討である．本研究の評価で用いた

究では，Kernel の各機能のみを有効にした Kernel をテストケースには，ネットワーク通信やセンシングなコンパイルし，起動して，Kernel イメージサイズやどの処理がない．そのため，一般的な IoT 機器の行メモリ使用量を計測した．Kernel の各機能ごとのメう動作と相違がある．また，lmbench による負荷は，

モリ使用量に着目している点で，本研究との関連が深

IoT 機器を通常使用している場合のものとは異なる．

い．しかし，ユーザープロセスの動作を考慮しないとより実際のユースケースに近いテストケースを用いるいう点が，本研究と異なる．本研究では，ユーザープ

ことで，本手法の有用性を更に評価する必要がある．

ロセスの挙動も考慮した，Linux Kernel Tinification

もう 1 つの課題は，Tinification の評価項目の追加でを目指す．

ある．本研究では，メモリ使用量と電力消費量に着Anil Kurmus ら（2013）は，アプリケーションを目して Linux Kernel の Tinification を行った．しか動作させた Linux Kernel を動的解析することで，必し，組み込みシステムに求められる特性は，それらだ

要十分な機能を特定し，Linux Kernel Tinification

けではない．起動時間の短さや，レイテンシの少なさを行う手法を確立した [2]．Kernel 内関数の呼び出しなどにも着目した，より発展した手法を確立したい．

に着目することで，Linux の各機能が使用されてい謝辞 本稿の統計的検定手法に関するアドバイスをるかどうかを判断した．Linux Kernel の不要な機能していただいた，公立はこだて未来大学の新美礼彦氏を特定しているという点が，本研究と類似している．

に感謝する．

参 考 文 献[1] Kaup, F., Gottschling, P., and Hausheer, D.:PowerPi: Measuring and modeling the power consumption of the Raspberry Pi, 39th Annual IEEE
Conference on Local Computer Networks, IEEE,
2014, pp. 236–243.
[2] Kurmus, A., Tartler, R., Dorneanu, D., Heinloth, B., Rothberg, V., Ruprecht, A., SchröderPreikschat, W., Lohmann, D., and Kapitza, R.: At-

tack Surface Metrics and Automated Compile-Time
OS Kernel Tailoring., NDSS, 2013.
[3] 雫石卓耶, 松原克弥, ほか: カーネル利用状況とメ
モリ使用量に着目した Linux Kernel Config の解析
手法, コンピュータシステム・シンポジウム論文集,
Vol. 2018(2018), pp. 81–89.
[4] 池田宗広: Linux カーネルサイズ・使用メモリ検証／
改善ＰＪ, 2006.
[5] 中島達夫ほか: 組込みシステム用標準 OS としてのLinux, 情報処理, Vol. 43, No. 2(2002), pp. 148–153.