さて、より細かな周期の設定は原理をみれば明らかで、たとえば、1[ms]単位で設定したいときは、タイマ割り込みの周期を1[ms]に すればいいわけです。

実際の修正個所ですが、/usr/src/linux/include/asm/param.h #ifndef _ASMi386_PARAM_H (Linux 2.2.13より) #define _ASMi386_PARAM_H #ifndef HZ #define HZ 100 #endif #define EXEC_PAGESIZE 4096 #ifndef NGROUPS #define NGROUPS 32 #endif #ifndef NOGROUP #define NOGROUP (-1) #endif #define MAXHOSTNAMELEN 64 /* max length of hostname */ #endif の定数 HZ を変更します。 デフォルトで100になっており、周期100[Hz]=10[ms]を意味します。ので、1[ms]=1000[Hz]でこれを1000にします。

以上でカーネルの改造は終了です。カーネルを再構築して、lilo設定して再起動してください。 なお、モジュールの再構築・インストールはしたほうがいいでしょう。このHZに依存するモジュールがわりとあります。 そのままモジュールをインストールすると、いままでのと混じる心配がありますので、ご注意下さい。 環境によっては、Makefile の頭の EXTRAVERSION に "-1k" とでも書くと、標準と異なるディレクトリにインストールされ、区別されるようです。

いちど、問題なく日常生活がおくれることが確認されたら、そのままそれを主環境にしてしまってもいいとおもいます。 現に私は長いことそんなカーネルで生活していましたが不具合はありませんでした。 ちょっとはパフォーマンスが落ちているはずですが(その分は少しクロックを上げて...)。

なお、以後、「HZを1000にしたカーネル」といちいち言うのも面倒なので「1k-linux」（いちきろ りなっくす／りぬくす）と表記します。 実際に、1k-linuxで同じプログラムを走らせてみましょう。 前と同じプログラムで、今度は5msの休眠を指定します(nice --20 ./cycle 5)。
結果を右図に示します。

まれに、図のように 1[ms]遅れることがありますが、基本的には6[ms]周期で実行されていることが確認できます。 ちなみに、cycleのデフォルトの15[ms]のままやると、16[ms]あたりになります。

このように、カーネルの定数を１つ変えただけで、普通の制御をするには十分な単周期で安定した実行が可能となります。

原理的にはHZを大きくしていけばより細かくなるはずですが、1000程度で留めておくことをおすすめします。 この先はどんどんパフォーマンスが低下し始めるはずですし、そもそも、そこまで細かくしても、この手法だとばらつきが大きくなりそうです。 もし、10k以上をねらうなら、やはり、RT-Linuxの導入を検討すべきでしょう。

優先度をあげるためには、１つのコマンド、２つの関数があります。 nice コマンド ： 優先度を上げ下げする nice -(優先度) 実行コマンド および その引数 #include int nice(int inc); システムコール inc: 優先度の上下分 #include #include int setpriority(int which, int who, int prio); which: PRIO_PROCESS(プロセス), PRIO_PGRP(プロセスグループ) PRIO_USER(ユーザ) who: それぞれのIDを指定。0 なら呼んだプロセスIDなど prio: 優先度 これらは共通して優先度(Scheduling priority)を操作します。 nice は優先度の上下を行います(現在値に対する相対指定)。 setpriority は絶対値を指定します。優先度は −20〜＋20で指定され、小さい方が優先度が高くなります(大きい方が"nice")。 いずれの関数も負の値を指定する(=優先度を上げる)には root の権限が必要となります。 とりあえずは、プログラムの頭にでもsetpriority(PRIO_PROCESS, 0, -20);と書いて、コンパイルしてrootで実行するか、 # chown root program; chmod +s program (programを実行するとき、だれがやってもrootで実行)するのがよいでしょう。 上の方法は、Linuxの普通のタイムシェアリングなスケジューラを使うため、"穏便に"優先度を上げるものです。 例え、優先度を最高にしているときに暴走させてしまったとしても、端末(kterm)などもちゃんと動作しますし、なんとでもなります。 それに対して、ここで紹介する方法は、スケジューリングの方法そのものを変え、絶対的な優先順位を指定します。 #include int sched_setscheduler(pid_t pid, int policy, const struct sched_param *p); struct sched_param { ... int sched_priority; ... }; この関数で policy に SCHED_FIFO, SCHED_RR を指定した場合に、スケジューリングがかわります(普段は SCHED_OTHER)。 これらを指定すると、実行可能状態の場合には必ずふつうのプロセスより優先的に処理されます(HZがおおむね1250以下の場合：それ以上の時は 定数を書き換える必要あり)。 この状態のプロセス同士の優先度は sched_param.sched_priority の数値(0:最低〜99:最高)で決まります。

この設定の恐いところは、もし、プログラムが無限ループにはまったりしたときに、端末も動かないので kill すらできなくなります。 処理の重いプログラムを周期実行かした場合には大きな効果が得られるとおもわれますが、普段、それほどはっきりした効果がみられるわけでもないので(上の手法で十分なことが多かったです)、使ってみて効果がなさそうなら、使わない方がいいかもしれません。

なお、SCHED_FIFO と SCHED_RR の違いですが、同じ優先度のプロセスが２個あったときに、SCHED_FIFO は順に処理、SCHED_RR は時間を区切って交互に処理するようになるようです。 プロセスの状態によっては、持ち時間の再計算処理の回数を増やすことで、優先度が高いプロセスの実行の確実性を上げることが可能です。 そのためには、持ち時間がすぐに空になる＝優先度最低のプロセスを常に走らせておきます。 優先度最低(20)のプロセスは、他のプロセスが全部休眠した状態で初めてCPUを得て、実行されます。 しかも、持ち時間がタイマ割り込み１回分しかないので、実行されるとすぐに持ち時間０。 スケジューリングの原理では実行可能な全プロセスの持ち時間が０になったら再計算、となっているので、すぐに再計算が行われます。 その結果、周期実行を含む休眠中のプロセスの持ち時間も増え、安定性が向上します。

やり方は簡単で、常に画像処理をしているようなプロセスがあれば、それの優先度を下げてやります。 そういったものが特にない場合は、ダミーのプログラムをつくって低い優先度で実行することで効果がありますが、無駄にCPUを動かすくらいなら、世界的な分散処理の研究のお手伝いをするのも手です。

ここまでの方法が"尊敬語"にあたるなら、この方法は"謙譲語"にあたります(謎)。