そんで以前から考えてたんですが、ここ数年マルチコアなCPUが増えました。基本Linuxは複数のCPUがあってもそれらは平等に扱いますが、「リアルタイム制御用のコアを設定できたら便利じゃないか？」と思ってたら、ART-Linuxがそれをつい最近（2013年3月）に発表してくれました。これはぜひとも試してみようと思い、記録をメモしておきます。
１．ART-LinuxのインストールするLinuxの準備
ART－LinuxはUbuntu-10.04(Lucid)のKernelを改造したもののようです。まずLucidをDLしてきて、それをマルチコアなマシンにインストールします。（手元で実験に使えそうなのがCore2Duoのマシンしかなかったので、これで。）32bit版をインストールしてください。
２．ART-Linuxのインストール（BSP)
1項でインストールしたUbuntuのkernelを産総研のART-LinuxのHPからDLしてきます。
linux-image-2.6.32-art-generic_20130227_i386.deb
linux-headers-2.6.32-art-generic_20130227_i386.deb
linux-source-2.6.32-art_20130227_all.deb
PAE（メモリ拡張用）とかありますが、今回はベーシックなものを。（ちなみにART-Linuxには32bitしかありません。とりあえずリアルタイムで動かす制御用アプリで64bitが必要な類のものは思いつかないのでいいと思いますが。）
これらをインストールします。
sudo dpkg -i linux-image-2.6.32-art_20130227_i386.deb linux-headers-2.6.32-art_20130227_i386.deb linux-source-2.6.32-art_20130227_all.deb
これでART-Linux（BSP用）のkernelがインストールされ、それ起動用にgrubの設定も追加してくれます。（つまり、元々のUbuntuも起動できます）
注：BSPというのはLinuxの通常業務を行うプロセスのことで、最低1コアは割り当てる必要があります。インストール直後はBSPに何コア割り当てるとかのkernel起動パラメータを設定してありませんので、この場合は2コアで動いてしまいますが、後々AP（リアルタイム用コア）を動かすまではそれで構いません。
３．サンプルプログラムの実行
さてインストールが成功したか確認してみます。BSPでもとりあえずこれまでのART-Linuxの機能はあるようです。（基本は厳密なタイマ管理ができるか、ということになると思いますが。BSPがアプリで占有できないので、ちょうどアプリが動きたいときにシステム作業が発生してしまうと止めようがないでしょうが、システムコールに影響されない厳密なタイマがあるだけでリアルタイムのアプリを書くのは楽になります）
#include <stdio.h>
#include <linux/art_task.h>
#include <time.h>
#include <sys/time.h>
double gettimeofday_sec()
{
struct timeval tv;
gettimeofday(&tv, NULL);
return (tv.tv_sec + (double)tv.tv_usec*1e-6);
}
void process(void)
{
register int i;
double start_t1;
double now_t1;
start_t1 = gettimeofday_sec();
art_enter( ART_PRIO_MAX, ART_TASK_PERIODIC, 1000000 );
/* Real Time Task Start */
for (i=0; i<100; i++) {
art_wait();
now_t1 = gettimeofday_sec();
printf("[%d] %10.30f\n", i, (now_t1 - start_t1));
}
putchar('\n');
art_exit();
/* Real Time Task exit */
}
int main(void)
{
process();
return 0;
}
以下のようにビルドします。
$ gcc -Wall -O sample1.c /usr/lib/art_syscalls.o
大体、100回loopすると以下のような感じになります。
[99] 99.9835
あれ？なんか少しだけ早く回ってる？ちょっと予想とずれてしまいましたが、art_wait()の精度の問題なのか、gettimeofday()の問題なのか、長時間（1時間くらい）のサンプルを書いてみるか、外部に信号を出して計測してみないとわかりません。
追記：
その後、さらに設定をいろいろと変えて実験してみました。結論から言うと、
①上記の結果はインストール途中の結果であり、BSPは2コアの設定になっていた。またAP用のメモリ設定（今後、書きます）もしていなかった。ただし、gnomeのdesktopは動いていた。
②BSP=1にして実験すると、[99] 100.052等安定して処理が遅れるようになっていった。現在のLinuxのタスクスイッチが1ms、しかもデフォルトのART-Linuxの割り込み最短時間が1msなのを合わせて考えると、それが一番なっとくのいく結果と思われる。
③さらにART-Linuxの割り込み最短時間=500usにしてみたが、さらに安定して毎回1ms程度遅れるようになった。（予測しやすくなった）
サンプルが1秒ごとに1行出力するよ、という意味ではないような気がします。もっともこちらもART-Linuxのタイマ管理をよく勉強せずにサンプルを使ってしまいましたが、正確なタイマがあってもこうなるでしょう。本当に1秒周期で1行出力したいなら、タイマで0.99秒ほどまち、それからは1秒たったかloopでチェックするようにしないとだめでしょう。逆に最初の結果（早く動いてしまう）ほうが、リアルタイムのプログラムを作るうえでは、動作予測がしづらく使いづらいです。デフォルトのままだと、gnomeの割り込み処理や、Core2DuoやNvidia（グラフィックボードがこれ使ってます）のドライバ周りの割り込み等、リアルタイムを乱す要因がたくさんあり、変な結果になったと思います。（ゲーム程度の60Hz程度の周期でリアルタイム性が確保できればいいというならこれでもいいですが、本気で1ms周期の制御したいならCLIベースで動作させないといけないでしょう。）
