リアルタイムカーネルパッチセット - 版の履歴

Kgx: 同期

2024-11-24T04:55:24Z

同期

← 古い版		2024年11月24日 (日) 13:55時点における版
1行目:		1行目:
	[[Category:カーネル]]		[[Category:カーネル]]
	[[en:Realtime kernel]]		[[en:Realtime kernel]]
	このページでは Linux カーネルのリアルタイムパッチセットや、スケジューリングの遅延を解決するために役立つユーティリティについて説明しています。		このページでは [[カーネル\|Linux カーネル]] のリアルタイムパッチセットや、スケジューリングの遅延を解決するために役立つユーティリティについて説明しています。

			{{Note\|1=リアルタイムカーネルのサポートは [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=baeb9a7d8b60b021d907127509c44507539c15e5 Linux 6.12] でマージされました。}}

	== リアルタイムとは ==		== リアルタイムとは ==

AshMyzk: /* インストール */ 同期

2022-11-06T13:40:19Z

インストール: 同期

← 古い版		2022年11月6日 (日) 22:40時点における版
16行目:		16行目:

	== インストール ==		== インストール ==

	~~[[AUR]] には~~ -rt パッチが適用~~された~~カーネルが多数存在します。主要な~~カーネル~~は {{~~AUR~~\|linux-rt}} と {{~~AUR~~\|linux-rt-lts}} です。どちらも標準の {{Pkg\|linux}} カーネルパッケージのコンフィグレーションを基にしています。linux-rt は -rt パッチの開発ブランチに追従しており、linux-rt-lts は rt パッチセットの安定ブランチに追従しています。		複数の -rt パッチ適用済みのカーネルが存在します。主な2つは {{Pkg\|linux-rt}} と {{Pkg\|linux-rt-lts}} です。どちらも、メインの {{Pkg\|linux}} カーネルパッケージをベースとしたコンフィグレーションを使用しています。linux-rt は -rt パッチの開発ブランチに追従しており、一方 linux-rt-lts は rt パッチセットの安定ブランチに追従しています。
⚫	{{Note\|新しくインストールしたカーネル~~は忘れずに~~ブートマネージャに追加~~してくださ~~い。}}

			また、{{AUR\|linux-rt-bfq-dev}} というものもあります。これは、-rt パッチの開発版をベースとしており、[https://algo.ing.unimo.it/people/paolo/disk_sched/ BFQ スケジューラ] ([https://www.phoronix.com/scan.php?page=news_item&px=BFQ-Queued-Linux-4.12 もう一つの参照]) を含みます。

		⚫	{{Note\|新しくインストールしたカーネルを[[ブートローダー]]に追加することを忘れないように!}}

	== スケジューリングレイテンシ ==		== スケジューリングレイテンシ ==

Kusanaginoturugi: Kusanaginoturugi がページ「リアルタイムカーネル」を「リアルタイムカーネルパッチセット」に移動しました

2022-07-21T02:14:15Z

Kusanaginoturugi がページ「リアルタイムカーネル」を「リアルタイムカーネルパッチセット」に移動しました

← 古い版		2022年7月21日 (木) 11:14時点における版
(相違点なし)

Kusakata.bot: Pkg/AUR テンプレートの更新

2018-06-10T10:04:28Z

Pkg/AUR テンプレートの更新

← 古い版		2018年6月10日 (日) 19:04時点における版
29行目:		29行目:

	== 遅延をテストするユーティリティ ==		== 遅延をテストするユーティリティ ==
	カーネルのスケジューリングレイテンシをチェックして、遅延が発生した原因を特定することができるツールは複数存在します。そのようなツールは {{~~aur~~\|rt-tests}} パッケージにまとめて含まれています。		カーネルのスケジューリングレイテンシをチェックして、遅延が発生した原因を特定することができるツールは複数存在します。そのようなツールは {{Pkg\|rt-tests}} パッケージにまとめて含まれています。

	=== cyclictest ===		=== cyclictest ===

Kusakata: 同期

2017-11-27T14:38:04Z

同期

← 古い版		2017年11月27日 (月) 23:38時点における版
48行目:		48行目:
	上記の例ではクアッドコア CPU 環境で優先度98のひとつのスレッド (SCHED_FIFO) が動作しており、別のターミナルで hackbench を実行しているためにシステムは負担状態になっています。一番重要なのはコア3で32マイクロ秒の遅延が検出されていることです。		上記の例ではクアッドコア CPU 環境で優先度98のひとつのスレッド (SCHED_FIFO) が動作しており、別のターミナルで hackbench を実行しているためにシステムは負担状態になっています。一番重要なのはコア3で32マイクロ秒の遅延が検出されていることです。

	詳しくは ~~[http~~://man.cx/cyclictest(8) ~~cyclictest(8)]~~ の man ページを参照。		詳しくは {{man\|8\|cyclictest\|url=https://man.cx/cyclictest(8)}} の man ページを参照。

	=== hackbench ===		=== hackbench ===
	待機状態のカーネルは低いレイテンシを表示しがちなので、本当の結果を得るにはある程度負担をかけることが重要です。rt-tests パッケージに含まれている hackbench というユーティリティを使うと良いでしょう。複数のスレッドまたはプロセスを生成して、ソケットやパイプでデータを交換します。長時間動作させるには -l パラメータを追加してください: {{ic\|hackbench -l 1000000}}。		待機状態のカーネルは低いレイテンシを表示しがちなので、本当の結果を得るにはある程度負担をかけることが重要です。rt-tests パッケージに含まれている hackbench というユーティリティを使うと良いでしょう。複数のスレッドまたはプロセスを生成して、ソケットやパイプでデータを交換します。長時間動作させるには -l パラメータを追加してください: {{ic\|hackbench -l 1000000}}。

	詳しくは ~~[http~~://man.cx/hackbench(8) ~~hackbench(8)]~~ の man ページを参照。		詳しくは {{man\|8\|hackbench\|url=https://man.cx/hackbench(8)}} の man ページを参照。

	=== hwlatdetect ===		=== hwlatdetect ===
85行目:		85行目:
	上記の結果では指定した15マイクロ秒の閾値を超えた16個の NMI が検知されており、検出された最大遅延は21マイクロ秒となっています。		上記の結果では指定した15マイクロ秒の閾値を超えた16個の NMI が検知されており、検出された最大遅延は21マイクロ秒となっています。

	~~[http~~://man.cx/~~hwlatdetect~~ hwlatdetect(8)] man ~~page.~~		詳しくは {{man\|8\|hwlatdetect\|url=https://man.cx/hwlatdetect(8)}} の man ページを参照。

			== 参照 ==

			* [https://rt.wiki.kernel.org Real-Time Linux Wiki]
			* [https://wiki.linuxfoundation.org/realtime/ realtime:start - Linux Foundation Wiki]
			* [https://www.linuxfoundation.org/blog/intro-to-real-time-linux-for-embedded-developers/ Intro to Real-Time Linux for Embedded Developers]

Kusakata: 翻訳

2017-04-22T16:29:02Z

翻訳

新規ページ

[[Category:カーネル]]
[[en:Realtime kernel]]
このページでは Linux カーネルのリアルタイムパッチセットや、スケジューリングの遅延を解決するために役立つユーティリティについて説明しています。

== リアルタイムとは ==
[[Wikipedia:ja:リアルタイムシステム|リアルタイム]]アプリケーションにはイベントが発生してからアプリケーションがイベントに対応するまでにかかる時間のデッドラインが存在します。許容できるデッドラインを守るために、特定のアプリケーションや環境がレスポンスを返す最大応答時間を正確に計算できるリアルタイムオペレーティングシステム (RTOS) が使われます。一般的な RTOS は優先順位を使用します。一番高い優先度が割り当てられたタスクについては、イベントが発生してから CPU は必ず決められた時間内に処理を行います。そのような RTOS ではタスクの[[Wikipedia:ja:レイテンシ|レイテンシ]]は同等以上の優先度が設定されているタスクによって決まり、優先度が低いタスクは全て無視できます。通常の OS (普通の Linux など) ではレイテンシはシステム上で動作している全てのタスクによって変わってくるため、ある程度複雑な環境ではデッドラインを守ることを必ずしも保証できません。[[Wikipedia:ja:プリエンプション|プリエンプション]]がオフになると時間が予測できなくなるためです。プリエンプションが切られている場合、高優先度のタスクも低優先度のタスクによって遅延が発生する可能性があります。

== リアルタイムパッチの仕組み ==
RT-Preempt パッチは Linux を完全にプリエンティブルなカーネルに書き換えます。主に以下のようなことが行われます:

* rtmutex を再実装することにより ([[Wikipedia:ja:スピンロック|スピンロック]]を使用する) カーネル内のロック機構をプリエンティブにします。
* spinlock_t と rwlock_t によって保護されている[[Wikipedia:ja:クリティカルセクション|クリティカルセクション]]がプリエンティブになります。raw_spinlock_t を使うことで (カーネル内に) ノンプリエンプティブなセクションを作成できます (API は spinlock_t と同じです)。
* カーネル内のスピンロックと[[Wikipedia:ja:セマフォ|セマフォ]]について[[Wikipedia:ja:優先度継承|優先度継承]]を実装します。
* 割り込みハンドラをプリエンティブなカーネルスレッドに変換します: RT-Preempt はソフト割り込みハンドラをカーネルスレッドのコンテキストで扱います。通常のユーザー空間プロセスのように task_struct が使われます。ただしカーネルコンテキストに IRQ を登録することが可能になります。
* Linux の旧式なタイマー API を高精度なカーネルタイマーとタイムアウト用のタイマーからなる仕組みに変換します。ユーザー空間の POSIX タイマーが高精度になります。

== インストール ==
[[AUR]] には -rt パッチが適用されたカーネルが多数存在します。主要なカーネルは {{AUR|linux-rt}} と {{AUR|linux-rt-lts}} です。どちらも標準の {{Pkg|linux}} カーネルパッケージのコンフィグレーションを基にしています。linux-rt は -rt パッチの開発ブランチに追従しており、linux-rt-lts は rt パッチセットの安定ブランチに追従しています。
{{Note|新しくインストールしたカーネルは忘れずにブートマネージャに追加してください。}}

== スケジューリングレイテンシ ==
スケジューラにとって、レイテンシとはイベントが発生してからイベントを処理するまでにかかった時間のことです。大抵の場合、割り込みハンドラが起動する前に割り込みが起こることで遅延が生まれますが、タイマーの期限切れなどによって発生することもあります。

レイテンシ自体は自然なことで、いつだって多少の遅延は存在しています。問題となるのは遅延がアプリケーションを正しく動作するのに必要なデッドラインを超過する場合です。デッドライン内に処理が終われば成功で、デッドラインを超過した場合、失敗です。

スケジューリングレイテンシが発生する要因は様々です。一部を挙げると (順番に意味はありません): システムの設定がおかしい、ハードウェアが要件を満たしていない、カーネルモジュールの実装に問題がある、CPU の電源管理、ハードウェアタイマーが不正確、[[Wikipedia:ja:システムマネジメントモード|SMI]]、[[Wikipedia:ja:同時マルチスレッディング|SMT]] など。

システムの最大スケジューリングレイテンシを計測する場合、システムを負担状態にする必要があります。大抵はアイドル状態のときよりもビジー状態のときに大きな遅延が発生します。自然的・人為的を問わず様々な条件でテストを実行してみることを推奨します。また、ディスクやネット IO、USB、グラフィックサブシステムなど本番環境で使用する全てのサブシステムに対して負担をかけてみると良いでしょう。

== 遅延をテストするユーティリティ ==
カーネルのスケジューリングレイテンシをチェックして、遅延が発生した原因を特定することができるツールは複数存在します。そのようなツールは {{aur|rt-tests}} パッケージにまとめて含まれています。

=== cyclictest ===
リアルタイムテストで使われるプログラムである cyclictest は最大スケジューリングレイテンシを確認して、レイテンシのスパイクを追跡します。cyclictest はスレッドが設定したタイマーの有効期限とスレッドが実行されるまでの間の時間を計測することによって動作します。

テストの実行例:

{{hc|# cyclictest --smp -p98 -m|
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 239.09 220.49 134.53 142/1304 23799

T: 0 (23124) P:98 I:1000 C: 645663 Min: 2 Act: 4 Avg: 4 Max: 23
T: 1 (23125) P:98 I:1500 C: 430429 Min: 2 Act: 5 Avg: 3 Max: 23
T: 2 (23126) P:98 I:2000 C: 322819 Min: 2 Act: 4 Avg: 3 Max: 15
T: 3 (23127) P:98 I:2500 C: 258247 Min: 2 Act: 5 Avg: 4 Max: 32
^C}}

上記の例ではクアッドコア CPU 環境で優先度98のひとつのスレッド (SCHED_FIFO) が動作しており、別のターミナルで hackbench を実行しているためにシステムは負担状態になっています。一番重要なのはコア3で32マイクロ秒の遅延が検出されていることです。

詳しくは [http://man.cx/cyclictest(8) cyclictest(8)] の man ページを参照。

=== hackbench ===
待機状態のカーネルは低いレイテンシを表示しがちなので、本当の結果を得るにはある程度負担をかけることが重要です。rt-tests パッケージに含まれている hackbench というユーティリティを使うと良いでしょう。複数のスレッドまたはプロセスを生成して、ソケットやパイプでデータを交換します。長時間動作させるには -l パラメータを追加してください: {{ic|hackbench -l 1000000}}。

詳しくは [http://man.cx/hackbench(8) hackbench(8)] の man ページを参照。

=== hwlatdetect ===
hwlatdetect を使うことで、通常以上の時間が費やされて、通常のカーネル実行をブロックして遅延を生み出している SMI を検知できます。カーネルモジュール (linux-rt と linux-rt-lts の両方に存在) とプロセスを起動してユーザーに結果を報告する python スクリプトから構成されます。システムが NMI を使用しているかどうか確認するには以下のコマンドを実行:
{{hc|$ grep NMI /proc/interrupts|
NMI: 3335 3336 3335 3335 Non-maskable interrupts}}

hwlatdetect カーネルモジュールは stop_machine() コールによって CPU で動作しているものを全てオフにすることで機能します。それから TSC (Time Stamp Counter) をポーリングして生成されたデータストリームに間隙が存在しないかチェックします。間隙の存在は NMI によって割り込みが発生したことを意味します。NMI 以外に間隙が生まれることはありません (TSC の実装が壊れている場合は除く)。検知する閾値を15マイクロ秒に設定してプログラムを120秒間実行するには:
{{hc|<nowiki># hwlatdetect --duration=120 --threshold=15</nowiki>|
hwlatdetect: test duration 120 seconds
parameters:
Latency threshold: 15us
Sample window: 1000000us
Sample width: 500000us
Non-sampling period: 500000us
Output File: None

Starting test
test finished
Max Latency: 21us
Samples recorded: 16
Samples exceeding threshold: 16
1408928107.0286324723 18 17
.
.
1408928180.0296881126 15 21
.
.
1408928212.0300332889 18 18}}

上記の結果では指定した15マイクロ秒の閾値を超えた16個の NMI が検知されており、検出された最大遅延は21マイクロ秒となっています。

[http://man.cx/hwlatdetect hwlatdetect(8)] man page.