ビルドできたものがちゃんと動くか確かめないといけません。かといって正式にインストールしてしまうのはちょっと困ります。（既にCentOS6でインストールされている古いものとぶつかります）
そこで、以下のコマンドを実行します。
$ made dev-install
これを行うと、しばらく時間がかかりますがビルドしたところに、install/というパッケージを作ってくれますが、install/program/sofficeで今ビルドしたものを直接実行できます。
実行してみると、、、、メニューがやはり英語だ(^_^;) まあローカライズの設定せずにやってますから、予想はしてましたけどね。とりあえず動くようです。
さて、今度はもっとパワーのあるマシンを用意してチャレンジしてみますか。
注：上記の複数バージョンが動く話、ベータバージョンに限るという情報がありました。（RCはだめとか）そういえば、このソースはLibreOffice4.1のパッケージ版おとしてるところからソースをとってきたんだけど、起動時のダイアログになぜかベータで表示されていたよな・・・・（Helpで見ると、Ver4.1.0.4となっており、もしかして4.1からの開発版？）
2013年9月4日水曜日
LibreOfficeのソースからのビルド：ビルド編
さて早速ビルドをはじめます。まず何もオプションをつけずに実行。
$ make
そうしたら何かのライブラリらしきものをLibreOfficeのサーバーから大量にwgetし始めました。
（よく調べたら、最初に"make fetch"しとけと注意書きがありました。(-_-;)）
随分時間がかかりましたが、しばらくビルドが進んで、png.hがないとエラーになりました。
当該箇所のソースを見ると、どうも描画ルーチンの模様。ということで以下のコマンドでlibpngの開発パッケージをインストール。
$ sudo yum install libpng-devel
autogen.shのチェックには入ってなかったようです。
更に数時間ビルドしてると、システムに入れてあったウイルススキャンが、ビルド中に/tmp以下に作成される作業用データをmalwareと警告してきて、ビルドが止まってしまいます。しばし悩みましたが、しかたなくビルド中はウイルススキャンを切りました。
更に数時間（とにかく時間がかかる・・・）、エラーがでて以下の３つのうち再チャレンジしてみろと。
Error: a unit test failed, please do one of:
export DEBUGCPPUNIT=TRUE # for exception catching
export GDBCPPUNITTRACE="gdb --args" # for interactive debugging
export VALGRIND=memcheck # for memory checking
and retry using: make CppunitTest_sd_filters_test
export DEBUGCPPUNIT=TRUEを試してみると少し進みましたが、その先でまたエラーがでて同じ推奨が・・・
エラーの内容がどうもunittest（単体試験）に失敗したとのこと、いやそんなの修正方法わかんないよ＼(-o-)／ 開発中の最新版はあきらめて、最新リリースの4.1のソースをDLしてきて再度チャレンジ。
しかしやはり単体試験で落ちる。VALGRINDのexportしたら、単体試験のところでmemory errorで落ちているといわれる始末。（basic_scannerの試験といわれても、scaannerのドライバ入っているかどうかもわからない）
仕方ない、本気でgdb見てみるかと思い、デバッグ可能にするオプションを探します。
./autogen.sh --disable-gconf --disable-gtk --without-junit --disable-cve-tests --enable-symbols
デバッグ可能にする以下のオプションでmake開始。
make -sr ENABLE_SYMBOLS=true
export DEBUGCPPUNIT=TRUE
export GDBCPPUNITTRACE="gdb --args"
を設定したが、単体試験のところでかかっても何も情報がでない。（どうもexceptionでプロセスの外に出てから、gdbにかかっている模様）よくエラーを見たら、いつの間にかVALGRINDもexportしていて、そちらの方でmemory errorをひっかけて停止していました。
VALGRINDは無効にしたところ、なぜか単体試験が通る（ビルドが先に進む）ようになった？？？
しかし恐ろしく時間がかかり（途中からのビルドなのに１０時間たっても終わらない）、特に単体試験がやたら時間がかかります。プロセスとメモリの利用状況を調べてみると、gdbが1.3GBのメモリを喰ってる！どうもGDBCPPUNITTRACEのフラグにより、gdb下でmakeが動いているようで、それが恐ろしくメモリをくい、swapの嵐になっているようです。（今回のマシンは古いのでメモリが1GBしかない）
ちょっと考え直してみましたが、これまでビルドが止まってたのは決まって単体試験でした。しかもマシンのパワーが貧弱なこともあり、夜通し動かしていたことがよくあり（この暑いさなかクーラーのない部屋で）、しかも普通のPCです。長時間動かして熱にメモリがやられていたのかもしれません。あるいはswapが激しくて、長時間運転のうちにハードエラーが起きたか。
あらためて残りの部分のビルドは素直にやってみたら、なんとか通りました。
（結局、デバッグ用シンボルの作成は意味なかったです）
PS
ちょっとこの単体試験でビルドが止まる現象を落ち着いて考え直してみました。最後にやっとビルドが通るようになったと書きましたが、実際にはある単体試験で止まっても、継続するとなぜか次では通り少し進んで、別の単体試験で止まるということを繰り返しました。
gdbのところでプロセスサイズの話をしましたが、今回初めてLibreOfficeをビルドしたので、各種機能をほとんど盛り込んで（withoutせずに）ビルドしました。そのためプロセスサイズが大きくなり、単体試験を続けて実行中、Heapのメモリがなくなってきた現象が発生したのかもしれません。
フル機能のLibreOffficeをビルドしようと思ったら64bitOSでないとダメ？
しかしやはり単体試験で落ちる。VALGRINDのexportしたら、単体試験のところでmemory errorで落ちているといわれる始末。（basic_scannerの試験といわれても、scaannerのドライバ入っているかどうかもわからない）
仕方ない、本気でgdb見てみるかと思い、デバッグ可能にするオプションを探します。
./autogen.sh --disable-gconf --disable-gtk --without-junit --disable-cve-tests --enable-symbols
デバッグ可能にする以下のオプションでmake開始。
make -sr ENABLE_SYMBOLS=true
export DEBUGCPPUNIT=TRUE
export GDBCPPUNITTRACE="gdb --args"
を設定したが、単体試験のところでかかっても何も情報がでない。（どうもexceptionでプロセスの外に出てから、gdbにかかっている模様）よくエラーを見たら、いつの間にかVALGRINDもexportしていて、そちらの方でmemory errorをひっかけて停止していました。
VALGRINDは無効にしたところ、なぜか単体試験が通る（ビルドが先に進む）ようになった？？？
しかし恐ろしく時間がかかり（途中からのビルドなのに１０時間たっても終わらない）、特に単体試験がやたら時間がかかります。プロセスとメモリの利用状況を調べてみると、gdbが1.3GBのメモリを喰ってる！どうもGDBCPPUNITTRACEのフラグにより、gdb下でmakeが動いているようで、それが恐ろしくメモリをくい、swapの嵐になっているようです。（今回のマシンは古いのでメモリが1GBしかない）
ちょっと考え直してみましたが、これまでビルドが止まってたのは決まって単体試験でした。しかもマシンのパワーが貧弱なこともあり、夜通し動かしていたことがよくあり（この暑いさなかクーラーのない部屋で）、しかも普通のPCです。長時間動かして熱にメモリがやられていたのかもしれません。あるいはswapが激しくて、長時間運転のうちにハードエラーが起きたか。
あらためて残りの部分のビルドは素直にやってみたら、なんとか通りました。
（結局、デバッグ用シンボルの作成は意味なかったです）
PS
ちょっとこの単体試験でビルドが止まる現象を落ち着いて考え直してみました。最後にやっとビルドが通るようになったと書きましたが、実際にはある単体試験で止まっても、継続するとなぜか次では通り少し進んで、別の単体試験で止まるということを繰り返しました。
gdbのところでプロセスサイズの話をしましたが、今回初めてLibreOfficeをビルドしたので、各種機能をほとんど盛り込んで（withoutせずに）ビルドしました。そのためプロセスサイズが大きくなり、単体試験を続けて実行中、Heapのメモリがなくなってきた現象が発生したのかもしれません。
フル機能のLibreOffficeをビルドしようと思ったら64bitOSでないとダメ？
2013年8月22日木曜日
LibreOfficeのソースからのビルド：準備編
ビルド環境はCentOS6で行う。手順１．と２．については前回も書きましたが、あらためて記載する。（そのわりには、fontconfigの件抜いちゃってますが）
１．
まずビルド環境を整備するのに、以下のコマンドを使えとlibreofficeのwikiに書いてあった。
$ sudo yum-builddep libreoffice # RedHat
しかし、何かlibreoffice-3.0.4のソースRPMが見つからないといってエラーで返される。
どうもビルドに必要なライブラリを落としてくる（RedHat系なので、当然rpmパッケージでDLします）が、ソースまでrpmパッケージで探そうとしているらしい。（自分で最新ソースをDLしてくるからいいのに・・・・）
結局、これで必要なものがDLされたかは疑問。（実際、この後あれが足りない、これが足りないと自分でライブラリをインストールしまくる必要があったのでダメだったんでしょう）
２．
続いてconfigureに相当する、autogen.sh（gitしてきたところに入っている）を実行する。とりあえずオプションなしで。（全機能ビルドしようとしちゃうだろうけど、最初は全然わからないので。）
まずでてきたのが、javac（javaコンパイラ）がないとのこと。
OSのインストール状況を見てみるとOpenJDKのruntimeが入っていた。（だからjavaはあるが、javacはない）
OpenJDK-Developnment Environmentをソフトウェア管理ツールを使用してインストール、これでjavacは解決した。
３．
次にでてきたのが、gperfがないということ。（ハッシュ関数生成用ライブラリだそうです）以下のコマンドで直接インストール。
$ sudo yum install gperf
４．
次にでてきたのが、インストール済みのdoxygen（設計書自動生成ツール）のバージョンが古い（現在、1.6が入っている。 1.8.4以上が欲しいといってきた）ということ。yum updateをやってみたが、CentOSのリポジトリではまだ新しいバージョンが登録されてないらしく、現状で最新とのこと。
特にdoxygenの出力が欲しいわけではないので、これをスルーするオプションを追加。（親切にもautogen.shが提案してきてくれた）
./autogen.sh --without-doxygen
５．
次にでてきたのが、libjpegのヘッダファイルがないということ。libjpegのパッケージ自体は入っているが、ヘッダファイルということは開発用のパッケージが必要ということと判断し、以下のコマンドでインストール。
$ sudo yum install libjpeg-devel
６．
次にでてきたのが、libxsltがないということ。先ほどのlibjpegと同じことだろうと考え、以下のコマンドで開発用パッケージをインストール。
$ sudo yum install libxslt-devel
７．
次にでてきたのが、X関係の開発環境がないということ。さすがにこれはマニュアルでインストールしていると大変なので、ソフトウェア管理ツールを使い、それらしいものをかたっぱしからインストール。（ほとんどインストールされていない状態でした。OSインストール時に昔は「X開発環境」という選択肢があったんですが、今回のは単なる「開発環境」の選択肢しかなくって、結果g++が入ってくれた程度でした。）
８．
次にでてきたのが、gconfがないということ。でもパッケージ関係で探すとgconf-editorしか見つかりません。これはgnomeの設定用ツールでGUI込みのものです。でも要求されているのは、GUIは要らないから設定ファイル関係を操作するものらしいんですが、単独ではパッケージが見つかりません。
LibreOfficeがなんでこんなもの必要なんだろうと調べてみると、gnome設定を直接サポートするパッケージ（libreofice-gnome）をビルドするのに必要ならしい。そもそもこの機能自体まだexperimental（実験的）なものなので、はずします。
./autogen.sh --without-doxygen --disable-gconf
９．
次にでてきたのが、dbus-glib-1がないということ。glibというからにはグラフィック・ライブラリに関するものと思われるが、聞いたことのない名称。ぐぐってみると、"GLb Bindings for D-Bus"というものらしく、D-Busというのが一種の（軽量な）プロセス間通信を提供するもので、元々はKDEプロジェクトで開発されたものが今では様々なものに移植され使われているとのこと。以下のコマンドで直接インストール。
$ sudo yum install dbus-glib-devel
１０．
次にでてきたのが、GTK-pluginがないとのこと。先ほどgconfをあきらめたので、これもdisableにすることにする。
./autogen.sh --without-doxygen --disable-gconf --disable-gtk
（おそらくこのあたりまでLibreOfficeに入れようとすると、gnomeやGTKのソースが必要になってくるんだろう。そうなると、そもそもgnome自体も標準でディストリビューションに入っている物から、自分でビルドしたものに変えないといけなくなるだろうし・・・手間が際限なく増えていく。）
１１．
次にでてきたのが、GSTREAMERがないとのこと。（何者かと思ったら、streaming media frameworkとのこと。）調べて、以下の２つをインストール。
$ sudo yum install gstreamer-devl
$ sudo yum install gstreamer-plugins-base-devel
１２．
次にでてきたのが、libGLUがないとのこと。（OpenGLのライブラリのうちのGLU）以下のコマンドでインストール。
$ sudo yum install mesa-libGLU-devel
１３．
次にでてきたのが、antがないとのこと。（java版のmake。なんでこんなものまで使うんだ？）以下のコマンドでインストール。
$ sudo yum install ant
１４．
次にでてきたのが、JUnitがないとのこと。（javaの単体試験モジュール。LibreOffice内にjava開発機能が含まれているのか？）さすがにこれはパス。
./autogen.sh --without-doxygen --disable-gconf --disable-gtk --without-junit
とりあえずこれでMakefileはできました。
１．
まずビルド環境を整備するのに、以下のコマンドを使えとlibreofficeのwikiに書いてあった。
$ sudo yum-builddep libreoffice # RedHat
しかし、何かlibreoffice-3.0.4のソースRPMが見つからないといってエラーで返される。
どうもビルドに必要なライブラリを落としてくる（RedHat系なので、当然rpmパッケージでDLします）が、ソースまでrpmパッケージで探そうとしているらしい。（自分で最新ソースをDLしてくるからいいのに・・・・）
結局、これで必要なものがDLされたかは疑問。（実際、この後あれが足りない、これが足りないと自分でライブラリをインストールしまくる必要があったのでダメだったんでしょう）
２．
続いてconfigureに相当する、autogen.sh（gitしてきたところに入っている）を実行する。とりあえずオプションなしで。（全機能ビルドしようとしちゃうだろうけど、最初は全然わからないので。）
まずでてきたのが、javac（javaコンパイラ）がないとのこと。
OSのインストール状況を見てみるとOpenJDKのruntimeが入っていた。（だからjavaはあるが、javacはない）
OpenJDK-Developnment Environmentをソフトウェア管理ツールを使用してインストール、これでjavacは解決した。
３．
次にでてきたのが、gperfがないということ。（ハッシュ関数生成用ライブラリだそうです）以下のコマンドで直接インストール。
$ sudo yum install gperf
４．
次にでてきたのが、インストール済みのdoxygen（設計書自動生成ツール）のバージョンが古い（現在、1.6が入っている。 1.8.4以上が欲しいといってきた）ということ。yum updateをやってみたが、CentOSのリポジトリではまだ新しいバージョンが登録されてないらしく、現状で最新とのこと。
特にdoxygenの出力が欲しいわけではないので、これをスルーするオプションを追加。（親切にもautogen.shが提案してきてくれた）
./autogen.sh --without-doxygen
５．
次にでてきたのが、libjpegのヘッダファイルがないということ。libjpegのパッケージ自体は入っているが、ヘッダファイルということは開発用のパッケージが必要ということと判断し、以下のコマンドでインストール。
$ sudo yum install libjpeg-devel
６．
次にでてきたのが、libxsltがないということ。先ほどのlibjpegと同じことだろうと考え、以下のコマンドで開発用パッケージをインストール。
$ sudo yum install libxslt-devel
７．
次にでてきたのが、X関係の開発環境がないということ。さすがにこれはマニュアルでインストールしていると大変なので、ソフトウェア管理ツールを使い、それらしいものをかたっぱしからインストール。（ほとんどインストールされていない状態でした。OSインストール時に昔は「X開発環境」という選択肢があったんですが、今回のは単なる「開発環境」の選択肢しかなくって、結果g++が入ってくれた程度でした。）
８．
次にでてきたのが、gconfがないということ。でもパッケージ関係で探すとgconf-editorしか見つかりません。これはgnomeの設定用ツールでGUI込みのものです。でも要求されているのは、GUIは要らないから設定ファイル関係を操作するものらしいんですが、単独ではパッケージが見つかりません。
LibreOfficeがなんでこんなもの必要なんだろうと調べてみると、gnome設定を直接サポートするパッケージ（libreofice-gnome）をビルドするのに必要ならしい。そもそもこの機能自体まだexperimental（実験的）なものなので、はずします。
./autogen.sh --without-doxygen --disable-gconf
９．
次にでてきたのが、dbus-glib-1がないということ。glibというからにはグラフィック・ライブラリに関するものと思われるが、聞いたことのない名称。ぐぐってみると、"GLb Bindings for D-Bus"というものらしく、D-Busというのが一種の（軽量な）プロセス間通信を提供するもので、元々はKDEプロジェクトで開発されたものが今では様々なものに移植され使われているとのこと。以下のコマンドで直接インストール。
$ sudo yum install dbus-glib-devel
１０．
次にでてきたのが、GTK-pluginがないとのこと。先ほどgconfをあきらめたので、これもdisableにすることにする。
./autogen.sh --without-doxygen --disable-gconf --disable-gtk
（おそらくこのあたりまでLibreOfficeに入れようとすると、gnomeやGTKのソースが必要になってくるんだろう。そうなると、そもそもgnome自体も標準でディストリビューションに入っている物から、自分でビルドしたものに変えないといけなくなるだろうし・・・手間が際限なく増えていく。）
１１．
次にでてきたのが、GSTREAMERがないとのこと。（何者かと思ったら、streaming media frameworkとのこと。）調べて、以下の２つをインストール。
$ sudo yum install gstreamer-devl
$ sudo yum install gstreamer-plugins-base-devel
１２．
次にでてきたのが、libGLUがないとのこと。（OpenGLのライブラリのうちのGLU）以下のコマンドでインストール。
$ sudo yum install mesa-libGLU-devel
１３．
次にでてきたのが、antがないとのこと。（java版のmake。なんでこんなものまで使うんだ？）以下のコマンドでインストール。
$ sudo yum install ant
１４．
次にでてきたのが、JUnitがないとのこと。（javaの単体試験モジュール。LibreOffice内にjava開発機能が含まれているのか？）さすがにこれはパス。
./autogen.sh --without-doxygen --disable-gconf --disable-gtk --without-junit
とりあえずこれでMakefileはできました。
2013年8月18日日曜日
builddepについて
ふとLibreOfficeをソースからフル・ビルドしてやろうと思い立ち、調べてみると案の定かなりの難物の模様。
まずソースをgitでおとしてこないといけませんが、これがかなり時間がかかり（家はフレッツ光の一般家庭用です、マンションなんかのシェアタイプとは違います）、1GB以上をDLするのに数時間かかりました。（速度が出ないところをみると、gitのサーバの能力の問題と思われます）
普通ならまず、./configureなんですが、最初に./autogen.shを実行しろとのこと。./configureの代わりみたいなんですが、FONTCONFIGのところでどうしてもエラーがでます。ビルドマシンはCentOS6.4ですが、調べてみるとパッケージはちゃんと入っています。（2.2以上を要求してきましたが、2.8が入っています）
ちょこちょこ調べてみると、同じエラーで悩んでいる方も多く、ビルド環境を整えるために以下を行えとありました。
# yum-builddep libreoffice # RedHat系
# apt-get build-dep libreoffice # Debian, Ubuntu系
ところがこれを実行しようとすると、どうもソースパッケージ（CentOSならソールRPM）を探しに行ってしまい、たまたま最新（4.x系）が見つからなくてエラーになります。
いやちょっと何よこれ、とコマンドの意味を調べたら、当該パッケージをビルドするのに必要なパッケージをとってくるものとのこと。ライブラリ関係はいいんですが、肝心のソースは本家のものでやらせてよ・・・・
ということで、あきらめて設定を手作業で修正してやらないとだめなようです。
PS:
英語のメーリングリストで有用な情報を見つけました。この./autogen.shではビルドに必要なヘッダファイル（*.h）があるかを見ているようで、パッケージとしてfontconfigが入っていてもだめで、fontconfig-develが入ってないとだめとのこと。早速インストールです。
# yum install fontconfig-devel
./autogen.shが無事先に進むようになりましたが、、、今後はPerlのところでひっかかりました。LibreOfficeを開発している人、どんなシステム環境で作業してるんだ＼(-o-)／
まずソースをgitでおとしてこないといけませんが、これがかなり時間がかかり（家はフレッツ光の一般家庭用です、マンションなんかのシェアタイプとは違います）、1GB以上をDLするのに数時間かかりました。（速度が出ないところをみると、gitのサーバの能力の問題と思われます）
普通ならまず、./configureなんですが、最初に./autogen.shを実行しろとのこと。./configureの代わりみたいなんですが、FONTCONFIGのところでどうしてもエラーがでます。ビルドマシンはCentOS6.4ですが、調べてみるとパッケージはちゃんと入っています。（2.2以上を要求してきましたが、2.8が入っています）
ちょこちょこ調べてみると、同じエラーで悩んでいる方も多く、ビルド環境を整えるために以下を行えとありました。
# yum-builddep libreoffice # RedHat系
# apt-get build-dep libreoffice # Debian, Ubuntu系
ところがこれを実行しようとすると、どうもソースパッケージ（CentOSならソールRPM）を探しに行ってしまい、たまたま最新（4.x系）が見つからなくてエラーになります。
いやちょっと何よこれ、とコマンドの意味を調べたら、当該パッケージをビルドするのに必要なパッケージをとってくるものとのこと。ライブラリ関係はいいんですが、肝心のソースは本家のものでやらせてよ・・・・
ということで、あきらめて設定を手作業で修正してやらないとだめなようです。
PS:
英語のメーリングリストで有用な情報を見つけました。この./autogen.shではビルドに必要なヘッダファイル（*.h）があるかを見ているようで、パッケージとしてfontconfigが入っていてもだめで、fontconfig-develが入ってないとだめとのこと。早速インストールです。
# yum install fontconfig-devel
./autogen.shが無事先に進むようになりましたが、、、今後はPerlのところでひっかかりました。LibreOfficeを開発している人、どんなシステム環境で作業してるんだ＼(-o-)／
2013年8月16日金曜日
Linuxプログラムのメモリ不足
人の作ったプログラム何ですが、やたらとmalloc（正確にはcallocの方）を使ったCプログラムがありました。それの動きがどうもおかしい（不安定）なんで、見てみると数百MBのデータファイルを最初に読み込ませていました。（データファイルの大きさは、利用する状況によって変わります）動いているマシンが、RHEL6 32bitとのことなんで、明らかにmallocに失敗していると思われます。
ところが、このプログラムmallocの結果を全然チェックしておらず、catchもしていません。またプログラムを使っている人たちもLinuxに関しては素人ということで、何が悪いのか理解させるのに一苦労。試しにちょっとサンプルプログラムを作って見ました。
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#define MALLOC_SIZE 100000
int main()
{
int i,j;
int *pt;
for (i=0; i<10000; i++) {
pt = (int *)calloc( MALLOC_SIZE, sizeof(int));
if (pt == NULL) {
printf("## calloc error!! i= %d ##\n", i);
exit(0);
}
for (j=0; j<MALLOC_SIZE; j++) {
pt[j] = i;
}
ところが、このプログラムmallocの結果を全然チェックしておらず、catchもしていません。またプログラムを使っている人たちもLinuxに関しては素人ということで、何が悪いのか理解させるのに一苦労。試しにちょっとサンプルプログラムを作って見ました。
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#define MALLOC_SIZE 100000
int main()
{
int i,j;
int *pt;
for (i=0; i<10000; i++) {
pt = (int *)calloc( MALLOC_SIZE, sizeof(int));
if (pt == NULL) {
printf("## calloc error!! i= %d ##\n", i);
exit(0);
}
for (j=0; j<MALLOC_SIZE; j++) {
pt[j] = i;
}
}
}
取得したメモリに値を書き込んでいるのは、こうして実際に何か使わないと、それまでは本当にメモリの取得につながらないからです。（最初、これで苦労しました）
さてこれで実行してみるとerrorが出たときの、iの値は8,017、あれ？毎回400KB近くのメモリを取得しているはずなのに、これだと3.2GBのメモリを取得したことになっちゃうぞ？確か、Linuxだと1プロセスの最大サイズは2GB弱で、そのうちStackが１GB、Heapが700MBくらいだったはず。おおすぎます。
そこでValgrindでチェックしてみると、i=6,910 2.764GBのheap要求がされたとのこと。（計算が合う）再度、ぐぐりましたが、どうも1プロセスでのサイズ制限はなくなり、4GBのどの空間をKernel用、Stack用、Heap用に用途わけするようになったみたいです。
マシンを占有できれば大きなプログラムを動かせますが、動作解析が更にやっかいになったようです。
2013年7月27日土曜日
ART-Linuxの実験 プロセス起動のリアルタイム性
さてサンプルで1secに１回プログラムが起きるようにしてみました。さて、他のプログラムが動いていたらどうなるでしょう？一般的には遅れが発生すると予想されます。
１．YouTubeを同時に動かす
CPU負荷が20%以下にしかなりませんが、サンプルプログラムの起動タイミングにはまるで影響がでませんでした。
これでは負荷が軽すぎるようです。
２．CPUを100%使用するfor-loopだけのプログラムを同時に動かす。
ところがこれでもサンプルプログラムの1sec毎の起動には影響がでません。（負荷をかけるプログラムの実行時間がサンプルプログラムと同時に動かすと若干realの実行時間が多くなりますので、負荷プログラムが同時に動くことによる影響はでているようです）
３．起動周期をかえる
ここまでAPは動かさず、ずっとBSPで実験してきました。BSPでも結構リアルタイム性は高いような気がしてきましたが、なんか変です。
ふと気づいたのが、サンプルプログラムが1sec毎のタスク起動だということです。実際にこれを使うプログラムなら1～10ms毎のタスク起動で使うでしょう。そこでサンプルを10ms毎のタスク起動にしてみました。（100回だったloopは10000回になります）普通にまたコンソールに出力したら、そこでボトルネックになりそうなので、ファイルへリダイレクトします。
（最終行）
[9999] 99.971077
ちょっとこれは予想外な値になりました。ほかのタスクは何も動いていません。（gnome-desktopは動いていましたが）artのtimerがどういう仕組みになっているのかわかりませんが、10ms毎と指定しているのに、ほんの少し早くトリガがかかってしまうようです。
４．APで実験する
同じサンプルをAP側で実行してみました。
（最終行）
[9999] 99.99090
さすがにさっきよりは正確ですね。それでもぎりぎりという感じです。
Core2やNVidiaのPCだとARTのタイマは遅れ気味になるという話を別のところで聞いたのですが、これだと逆に早くなってない？という感じです。ただまあ、あきらかにAPを使うシステムの方がリアルタイム性にはすぐれていそうな雰囲気ではあります。
ただART-linuxのデフォルトのタイマ分解能は1msだとのことなので、10ms周期のタスク制御がぎりぎりかなあという感じではあります。（元がLinuxベースなのでしょうがない？
PS
先ほど「タイマ分解能」と書きましたが、正確には実時間割り込み周期の最短時間のことです。特に設定せずに実験していましたが、ちょっと気になって設定して同じことをしてみました。
grubで起動するときに、ART=***というオプションを追加します。単位はusですので、デフォルトはART=1000だと思っていました。これをART=500で起動してみると明らかにタイマ割り込みが遅くなってしまいました。（BSP、AP両方とも）割り込み処理の負荷が耐え切れなくなったのか？と思い、ART=1000にしてみました。これでもとに戻るかと思ったら、ほぼデフォルトには近くなりましたが、タイマの精度がよくありません。
内部タイマで実験してもそろそろ限界のようなので、外部で計測してみないとだめのようです。（あるいはもっと長時間計測用プログラムを動かして、誤差の蓄積を多くする）
１．YouTubeを同時に動かす
CPU負荷が20%以下にしかなりませんが、サンプルプログラムの起動タイミングにはまるで影響がでませんでした。
これでは負荷が軽すぎるようです。
２．CPUを100%使用するfor-loopだけのプログラムを同時に動かす。
ところがこれでもサンプルプログラムの1sec毎の起動には影響がでません。（負荷をかけるプログラムの実行時間がサンプルプログラムと同時に動かすと若干realの実行時間が多くなりますので、負荷プログラムが同時に動くことによる影響はでているようです）
３．起動周期をかえる
ここまでAPは動かさず、ずっとBSPで実験してきました。BSPでも結構リアルタイム性は高いような気がしてきましたが、なんか変です。
ふと気づいたのが、サンプルプログラムが1sec毎のタスク起動だということです。実際にこれを使うプログラムなら1～10ms毎のタスク起動で使うでしょう。そこでサンプルを10ms毎のタスク起動にしてみました。（100回だったloopは10000回になります）普通にまたコンソールに出力したら、そこでボトルネックになりそうなので、ファイルへリダイレクトします。
（最終行）
[9999] 99.971077
ちょっとこれは予想外な値になりました。ほかのタスクは何も動いていません。（gnome-desktopは動いていましたが）artのtimerがどういう仕組みになっているのかわかりませんが、10ms毎と指定しているのに、ほんの少し早くトリガがかかってしまうようです。
４．APで実験する
同じサンプルをAP側で実行してみました。
（最終行）
[9999] 99.99090
さすがにさっきよりは正確ですね。それでもぎりぎりという感じです。
Core2やNVidiaのPCだとARTのタイマは遅れ気味になるという話を別のところで聞いたのですが、これだと逆に早くなってない？という感じです。ただまあ、あきらかにAPを使うシステムの方がリアルタイム性にはすぐれていそうな雰囲気ではあります。
ただART-linuxのデフォルトのタイマ分解能は1msだとのことなので、10ms周期のタスク制御がぎりぎりかなあという感じではあります。（元がLinuxベースなのでしょうがない？
PS
先ほど「タイマ分解能」と書きましたが、正確には実時間割り込み周期の最短時間のことです。特に設定せずに実験していましたが、ちょっと気になって設定して同じことをしてみました。
grubで起動するときに、ART=***というオプションを追加します。単位はusですので、デフォルトはART=1000だと思っていました。これをART=500で起動してみると明らかにタイマ割り込みが遅くなってしまいました。（BSP、AP両方とも）割り込み処理の負荷が耐え切れなくなったのか？と思い、ART=1000にしてみました。これでもとに戻るかと思ったら、ほぼデフォルトには近くなりましたが、タイマの精度がよくありません。
内部タイマで実験してもそろそろ限界のようなので、外部で計測してみないとだめのようです。（あるいはもっと長時間計測用プログラムを動かして、誤差の蓄積を多くする）
2013年7月23日火曜日
ART-Linuxの実験 再インストール
しばらく時間が開いてしまいましたが、5月末にART-Linuxをインストールしていた実験PCがおかしくなってしまったんです。その後、まとまった時間がとれないのと、当該実験PCがWindowsXPとのマルチブートでそっちもおかしくなってしまい、XPからの再インストールとなってしまい、大変でした。
さてART-Linuxの設定は前回記録を残したので、特に問題なく設定できましたが、前回でも問題になったのがAP（アプリケーションプロセッサ）の起動です。このAP、本体（BSP：ベースプロセッサと呼ぶようです）のファイルシステムの一部に自分のroot-fsを構築していて、そこをなぜかNFSで利用します。（この理由がわからんが、これに苦しめられています）
最初にインストールしたUbuntuがDesktop版のせいか、クライアントには簡単になれますが、サーバーになるためのパッケージやら設定が全然入っていません。どうしてもNFSサーバーとして起動してくれないんで、APの起動がうまくいかないんです。
おまけにAP用のEtherとして特別のルーター設定もしているせいか、結局全部手動でやらないといけない状態ですが、とりあえず手順をまとめます。
１．マシン起動（BSPが立ち上がります）
２．AP用のコンソールを起動します。
$ sudo screen /dev/ttyAP0
３．別のshellでAP用のネットを起動します。
$ sudo ifup ap0
４．あらためてNFSのファイルシステムの公開を宣言します。
$ sudo exportfs -a
５．まずNFSのために、portmapを起動します。
$ sudo /etc/init.d/portmap start
６．次にNFSサーバーを起動します。
$ sudo /etc/init.d/nfs-kernel-server restart
７．これで準備が整いました。apbootをします。
NFSサーバーを起動するのにまずportmapを起動しないといけないんですが、どうもUbuntuのdesktopはこのあたりの設定に問題があるらしく、起動してきれません。なので先に５．の手順をしておかないと、６．のところで応答がかえってこなくなります。
あとAPではプログラムのコンパイルができません。BSP側で実行形式を作成し、AP側のfsにコピーしてやればいいんですが、基本root権限でコピーしてやる必要があります。
なんちゅうか、まだまだ研究室の中で使用されるレベルです。（やっと実験環境が戻った・・・・）
さてART-Linuxの設定は前回記録を残したので、特に問題なく設定できましたが、前回でも問題になったのがAP（アプリケーションプロセッサ）の起動です。このAP、本体（BSP：ベースプロセッサと呼ぶようです）のファイルシステムの一部に自分のroot-fsを構築していて、そこをなぜかNFSで利用します。（この理由がわからんが、これに苦しめられています）
最初にインストールしたUbuntuがDesktop版のせいか、クライアントには簡単になれますが、サーバーになるためのパッケージやら設定が全然入っていません。どうしてもNFSサーバーとして起動してくれないんで、APの起動がうまくいかないんです。
おまけにAP用のEtherとして特別のルーター設定もしているせいか、結局全部手動でやらないといけない状態ですが、とりあえず手順をまとめます。
１．マシン起動（BSPが立ち上がります）
２．AP用のコンソールを起動します。
$ sudo screen /dev/ttyAP0
３．別のshellでAP用のネットを起動します。
$ sudo ifup ap0
４．あらためてNFSのファイルシステムの公開を宣言します。
$ sudo exportfs -a
５．まずNFSのために、portmapを起動します。
$ sudo /etc/init.d/portmap start
６．次にNFSサーバーを起動します。
$ sudo /etc/init.d/nfs-kernel-server restart
７．これで準備が整いました。apbootをします。
NFSサーバーを起動するのにまずportmapを起動しないといけないんですが、どうもUbuntuのdesktopはこのあたりの設定に問題があるらしく、起動してきれません。なので先に５．の手順をしておかないと、６．のところで応答がかえってこなくなります。
あとAPではプログラムのコンパイルができません。BSP側で実行形式を作成し、AP側のfsにコピーしてやればいいんですが、基本root権限でコピーしてやる必要があります。
なんちゅうか、まだまだ研究室の中で使用されるレベルです。（やっと実験環境が戻った・・・・）
登録:
投稿 (Atom)