DRAWMINOS
作って保存できるみたい．
こういうの，ついついやっちゃうw
参考ページ：
ブラウザ上でドミノ倒しゲームを作って遊べる「DRAWMINOS」 - japan.internet.com Webビジネス
2008年11月29日土曜日
2008年11月27日木曜日
Rubyのインストール
スクリプトを作るのにRubyを使ってみることにしました．
昔まつもとさんの講演を聞きに行って，最も自然言語に近いスクリプト言語ということで興味があったので．
ここからダウンロード
Ruby Install Guideを参考にインストール
以降，そのページにありますが，一応やったことをメモ．
% tar xvf ruby-1.8.7-p72.tar.gz
% cd ruby-1.8.7-p72
% ./configure
% make
% su
# make install
# exit
% make clean
デフォルトでは/usr/local 以下にインストールされるようです．
% ruby -v
とすると，バージョンが表示され，ちゃんとインストールできていることが確認できました．
よーし，初Ruby挑戦♪♪
公式ページのチュートリアルはプログラミング初心者向けで読みやすいですw
昔まつもとさんの講演を聞きに行って，最も自然言語に近いスクリプト言語ということで興味があったので．
ここからダウンロード
Ruby Install Guideを参考にインストール
以降，そのページにありますが，一応やったことをメモ．
% tar xvf ruby-1.8.7-p72.tar.gz
% cd ruby-1.8.7-p72
% ./configure
% make
% su
# make install
# exit
% make clean
デフォルトでは/usr/local 以下にインストールされるようです．
% ruby -v
とすると，バージョンが表示され，ちゃんとインストールできていることが確認できました．
よーし，初Ruby挑戦♪♪
公式ページのチュートリアルはプログラミング初心者向けで読みやすいですw
2008年11月25日火曜日
リアルタイムプロセス
プロセスをリアルタイムプロセスにするには，sched_setschedulerを用いる．
sched_setscheduler(pid_t pid, int policy,const struct sched_param *param);
pid:プロセスID(自身をリアルタイムプロセスにするには0を設定)
policy:どのようなスケジューリングに設定するかのポリシー
(リアルタイム：SCHED_FIFO，SCHED_RR
リアルタイムでない：SCHED_OTHER，SCHED_BATCH，SCHED_IDLE)
●使用例：より正確に時間を計測したい場合
#include
struct sched_param *param;
int main(){
……
sched_setscheduler(0,SCHED_RR,param);
sleep(sleep_interval);
sched_setscheduler(0,SCHED_OTHER,param);
……
}
参照ページ：
Manpage of SCHED_SETSCHEDULER
sched_setscheduler(pid_t pid, int policy,const struct sched_param *param);
pid:プロセスID(自身をリアルタイムプロセスにするには0を設定)
policy:どのようなスケジューリングに設定するかのポリシー
(リアルタイム：SCHED_FIFO，SCHED_RR
リアルタイムでない：SCHED_OTHER，SCHED_BATCH，SCHED_IDLE)
●使用例：より正確に時間を計測したい場合
#include
struct sched_param *param;
int main(){
……
sched_setscheduler(0,SCHED_RR,param);
sleep(sleep_interval);
sched_setscheduler(0,SCHED_OTHER,param);
……
}
参照ページ：
Manpage of SCHED_SETSCHEDULER
2008年11月23日日曜日
ファイルの中身を検索する
「この構造体どこに定義してあるのッ(怒)」というときのために．
shell> grep -r 文字列 *
これで全ファイル内から文字列を検索できる．
特定のファイルから文字列を検索するには，
shell> grep 文字列 ファイル名
でOK
shell> grep -r 文字列 *
これで全ファイル内から文字列を検索できる．
特定のファイルから文字列を検索するには，
shell> grep 文字列 ファイル名
でOK
2008年11月22日土曜日
精度の高いSLEEP
sleep関数では，秒単位でしかsleepのインターバルを指定できません．
更に精度の高いsleepを使用したい場合には，usleepとnanosleepの2つがあります．
usleepは今はあまり推奨されていないようなので，一般的にはnanosleepのよう．
カーネル2.4系ではこの関数をリアルタイムプロセス内で使う必要があったようですが，今現在はその必要はないとのこと．
参照ページ：
Manpage of USLEEP
Manpage og NANOSLEEP
更に精度の高いsleepを使用したい場合には，usleepとnanosleepの2つがあります．
usleepは今はあまり推奨されていないようなので，一般的にはnanosleepのよう．
カーネル2.4系ではこの関数をリアルタイムプロセス内で使う必要があったようですが，今現在はその必要はないとのこと．
参照ページ：
Manpage of USLEEP
Manpage og NANOSLEEP
2008年11月19日水曜日
使用するCPUの数の制御
マルチプロセッサのコア数を減らすためには，BIOSで設定が必要．
だと思っていたのですが，
使用するCPUの数を減らすには
% echo 0 > /sys/devices/system/cpu/cpu1/online
でCPU1を，不使用にできる．
元に戻したい場合は/sys/devices/system/cpu/cpu1/onlineの値を1に直せば良い．
他CPU2,CPU3なども同じように設定することで制御可能．
すごい便利！
ちなみにrebootする度に値は1になります．
/*** 追記(2008/11/28)
これは，スケジューリングをするときにこのonlineの値を見てそのCPUを使う/使わないを判断しているためだろうとのこと．
だからrebootなどが必要ないのですね．
他にもCPUのfrequencyなどもここで制御できるようで，省エネのためなのでは，と先輩が言っていました．
***/
だと思っていたのですが，
使用するCPUの数を減らすには
% echo 0 > /sys/devices/system/cpu/cpu1/online
でCPU1を，不使用にできる．
元に戻したい場合は/sys/devices/system/cpu/cpu1/onlineの値を1に直せば良い．
他CPU2,CPU3なども同じように設定することで制御可能．
すごい便利！
ちなみにrebootする度に値は1になります．
/*** 追記(2008/11/28)
これは，スケジューリングをするときにこのonlineの値を見てそのCPUを使う/使わないを判断しているためだろうとのこと．
だからrebootなどが必要ないのですね．
他にもCPUのfrequencyなどもここで制御できるようで，省エネのためなのでは，と先輩が言っていました．
***/
2008年11月17日月曜日
Linux Performance Counters Driver
PAPI(前日記参照)を用いてシステムワイドな値がとれないということが発覚しました…
PAPIはあくまでもプログラムごとのハードウェアカウンタの値を見るもので，このプログラムだとキャッシュミスが多いな…などといったことを発見し，プログラムのチューンアップを行うもののようです．
しかし，PAPIをインストールした際に，kernelにパッチをあてた，
Linux Performance Counters Driver(perfctr)を利用すれば，システムワイドな値がとれる様子．
しかしこれ，ドキュメントがない！
ので，ソースを見て解読するしかないっぽいです
とりあえずサンプルコードはあるので，真似して使えるようにならねば．
PAPIはあくまでもプログラムごとのハードウェアカウンタの値を見るもので，このプログラムだとキャッシュミスが多いな…などといったことを発見し，プログラムのチューンアップを行うもののようです．
しかし，PAPIをインストールした際に，kernelにパッチをあてた，
Linux Performance Counters Driver(perfctr)を利用すれば，システムワイドな値がとれる様子．
しかしこれ，ドキュメントがない！
ので，ソースを見て解読するしかないっぽいです
とりあえずサンプルコードはあるので，真似して使えるようにならねば．
2008年11月13日木曜日
su と su- の違い
スーパユーザになるときのコマンド，「su」に関して．
ハイフンをつけない/つけるで，コマンド実行前のユーザーアカウントの操作環境を引き継ぐか，root仕様にするかが変わるみたいです．
(知らなかったー！気まぐれだと思ってました笑)
・su の場合
rootになったときに，ユーザアカウントの動作環境を引き継ぐため，
・ディレクトリが移動しない
・環境変数が一般ユーザのまま
→一般ユーザのデフォルトのPATHには"/usr/sbin/"が含まれていないため，実行時にパスを付けて実行しなければならない
・su - の場合
rootになったときに，rootの動作環境を用いるため，
・ディレクトリが"root"になる
・環境変数がroot仕様になる
→PATHに"/usr/sbin/"が含まれている
だから，なるべくハイフンをつけた方がいいような気がしますね．
ハイフンをつけない/つけるで，コマンド実行前のユーザーアカウントの操作環境を引き継ぐか，root仕様にするかが変わるみたいです．
(知らなかったー！気まぐれだと思ってました笑)
・su の場合
rootになったときに，ユーザアカウントの動作環境を引き継ぐため，
・ディレクトリが移動しない
・環境変数が一般ユーザのまま
→一般ユーザのデフォルトのPATHには"/usr/sbin/"が含まれていないため，実行時にパスを付けて実行しなければならない
・su - の場合
rootになったときに，rootの動作環境を用いるため，
・ディレクトリが"root"になる
・環境変数がroot仕様になる
→PATHに"/usr/sbin/"が含まれている
だから，なるべくハイフンをつけた方がいいような気がしますね．
2008年11月4日火曜日
PAPIのインストール
PAPI：Performance Application Programming Interface
ハードウェアカウンタを見ることができるAPIです．
まずはここから最新版をダウンロード．
INSTALLガイドを見ると，カーネルにパッチをあてる必要があるようで.
(Linux/x86)
●kernel●
まずは，カーネルをダウンロード．
パッチのバージョンと合うように，今回は2.6.25をダウンロード．
/usr/src/kernels内に展開．
そのディレクトリに移動．
shell> cp ../linux-2.6.23/.config .
-今まで使っていた.configファイルをディレクトリ内にコピー
shell> make mrproper
-お掃除
shell> papi-3.6.2/src/perfctr-2.6.x/update-kernel
-perfctr(Performance Monitoring Counters Driver)をカーネル内に入れるためのパッチあて
shell> make oldconfig
-さっきコピーしたconfigファイルを引き継ぐ
shell> make menuconfig
-更にinstallガイドの沿って設定を行う("PERCESSOR TYPE AND FEATURES"内のPerformance MoniteringをMにして，中のものに全てチェックをつけるetc)
shell> make bzImage
-bzImageというカーネルイメージを作成
shell> make modules
-モジュール作成
shell> make modules_install
-/lib/modules/下にモジュールがインストールされる．
shell> make install
-/boot/以下にカーネルイメージなどが作成される．
ブートローダの設定
/etc/grub.confのdefaultの値を1から0に書き換えることで，デフォルトで起動するカーネルイメージを変更できる．
(/etc/grub.confに新しく入れたカーネルのバージョンが書き足されているため，default値は，0から1に変わっているので)
で，reboot!!
2.6.25で起動します．
●Dynamic /dev (udev)●
Linuxのいろんなバージョンに適合させるための作業
papi-3.6.2/src/perfctr-2.6.x/下で行います
shell> cp etc/perfctr.rules /etc/udev/rules.d/99-perfctr.rules
-perfctrがカーネルにロードされたときに，udevが，全ユーザのアクセスできる/dev/perfctrを作成するためのルールを追加
shell> cp etc/perfctr.rc /etc/rc.d/init.d/perfctr
-カーネルがperfctrモジュールを自動で呼ぶことを可能とするためのスクリプトを追加
shell> chmod 755 /etc/rc.d/init.d/perfctr
shell> /sbin/chkconfig --add perfctr
-perfctrという新しいシステムサービスを追加(詳細は@IT)
rebootする．
shell> papi-3.6.2/src/perfctr-2.6.x/examples/perfex/perfex -i
とすると，
なんだかOKそうな値がちゃんと出ました!!
PerfCtr Info:
abi_version 0x05020501
driver_version 2.6.35 DEBUG
cpu_type 18 (Intel Core 2)
cpu_features 0x7 (rdpmc,rdtsc,pcint)
cpu_khz 2394142
tsc_to_cpu_mult 1
cpu_nrctrs 5
cpus [0,1,2,3], total: 4
cpus_forbidden [], total: 0
基礎作り終了．
●PAPIインストール●
papi-3.6.2/src/下で行う
shell> ./configure
shell> make
shell> make test
-テストを１つ行う．良い結果が出たら次へ．
shell> make fulltest
PAPIインストール終了ー！
次は，doc/下のUSER'S GUIDE見たりして使い方のお勉強です．
ハードウェアカウンタを見ることができるAPIです．
まずはここから最新版をダウンロード．
INSTALLガイドを見ると，カーネルにパッチをあてる必要があるようで.
(Linux/x86)
●kernel●
まずは，カーネルをダウンロード．
パッチのバージョンと合うように，今回は2.6.25をダウンロード．
/usr/src/kernels内に展開．
そのディレクトリに移動．
shell> cp ../linux-2.6.23/.config .
-今まで使っていた.configファイルをディレクトリ内にコピー
shell> make mrproper
-お掃除
shell> papi-3.6.2/src/perfctr-2.6.x/update-kernel
-perfctr(Performance Monitoring Counters Driver)をカーネル内に入れるためのパッチあて
shell> make oldconfig
-さっきコピーしたconfigファイルを引き継ぐ
shell> make menuconfig
-更にinstallガイドの沿って設定を行う("PERCESSOR TYPE AND FEATURES"内のPerformance MoniteringをMにして，中のものに全てチェックをつけるetc)
shell> make bzImage
-bzImageというカーネルイメージを作成
shell> make modules
-モジュール作成
shell> make modules_install
-/lib/modules/下にモジュールがインストールされる．
shell> make install
-/boot/以下にカーネルイメージなどが作成される．
ブートローダの設定
/etc/grub.confのdefaultの値を1から0に書き換えることで，デフォルトで起動するカーネルイメージを変更できる．
(/etc/grub.confに新しく入れたカーネルのバージョンが書き足されているため，default値は，0から1に変わっているので)
で，reboot!!
2.6.25で起動します．
●Dynamic /dev (udev)●
Linuxのいろんなバージョンに適合させるための作業
papi-3.6.2/src/perfctr-2.6.x/下で行います
shell> cp etc/perfctr.rules /etc/udev/rules.d/99-perfctr.rules
-perfctrがカーネルにロードされたときに，udevが，全ユーザのアクセスできる/dev/perfctrを作成するためのルールを追加
shell> cp etc/perfctr.rc /etc/rc.d/init.d/perfctr
-カーネルがperfctrモジュールを自動で呼ぶことを可能とするためのスクリプトを追加
shell> chmod 755 /etc/rc.d/init.d/perfctr
shell> /sbin/chkconfig --add perfctr
-perfctrという新しいシステムサービスを追加(詳細は@IT)
rebootする．
shell> papi-3.6.2/src/perfctr-2.6.x/examples/perfex/perfex -i
とすると，
なんだかOKそうな値がちゃんと出ました!!
PerfCtr Info:
abi_version 0x05020501
driver_version 2.6.35 DEBUG
cpu_type 18 (Intel Core 2)
cpu_features 0x7 (rdpmc,rdtsc,pcint)
cpu_khz 2394142
tsc_to_cpu_mult 1
cpu_nrctrs 5
cpus [0,1,2,3], total: 4
cpus_forbidden [], total: 0
基礎作り終了．
●PAPIインストール●
papi-3.6.2/src/下で行う
shell> ./configure
shell> make
shell> make test
-テストを１つ行う．良い結果が出たら次へ．
shell> make fulltest
PAPIインストール終了ー！
次は，doc/下のUSER'S GUIDE見たりして使い方のお勉強です．
2008年11月3日月曜日
Linuxインストールしました
やっとこさ家のパソコンに．
謎にfirefoxが「Could not find compatible GRE between version 1.9b and 1.9b」というエラーを出して起動しなくなった．
xulrunnerというランタイムパッケージとのバージョンが合わなくなったって意味らしい．
色々探したけどイマイチよく分からなかったので，単純にyumでfirefoxをアップデートしてみた．
そうしたら，問題なくあがるようになった笑
謎．
Fedora9は，標準インストールでは日本語入力できないみたい．
Fedora 9で日本語を入力するには － ＠IT
この設定を終えて一度ログアウトしたらちゃんと使えるようになった♪
これで，ctrl + space キーでも，半角/全角キーでも日本語入力ができるようになりました．
分からないことだらけだなぁ(*_*;)
謎にfirefoxが「Could not find compatible GRE between version 1.9b and 1.9b」というエラーを出して起動しなくなった．
xulrunnerというランタイムパッケージとのバージョンが合わなくなったって意味らしい．
色々探したけどイマイチよく分からなかったので，単純にyumでfirefoxをアップデートしてみた．
そうしたら，問題なくあがるようになった笑
謎．
Fedora9は，標準インストールでは日本語入力できないみたい．
Fedora 9で日本語を入力するには － ＠IT
この設定を終えて一度ログアウトしたらちゃんと使えるようになった♪
これで，ctrl + space キーでも，半角/全角キーでも日本語入力ができるようになりました．
分からないことだらけだなぁ(*_*;)
Hardware Counter Driven On-the-Fly Request Signatures
ASPLOS'08の，Kai Shenさんたちの論文です．
ハードウェアカウンタの値を用いて実行中のリクエストを早期識別しちゃおう！というスゴイ話．
ゼミでやったので詳しめにまとめ．
(先輩方に色々フォローしてもらって勉強になりました！もっとしっかり読めるようになりたい)
●背景＆問題点●
OSは，実行時のワークロードのプロパティを知ることで，より良いスケジューリングが可能になったり，コストを抑えたNWサービスが可能となる．
しかし，現状では，過去のリクエストからワークロードのプロパティを予測する手法がとられている．
この手法では，入力パターンが多く，実行時の状態が変化するワークロードの予測を当てることは難しい．
●提案●
サーバリクエストを実行中の早い段階で識別し，プロパティを予測しよう．
－プロパティとは：メモリ使用量，CPU使用量，I/O発行量など
この，リクエストの識別は，ハードウェアカウンタの値を数個組み合わせてシグネチャとすることで可能となる．
●ハードウェアカウンタの組み合わせ●
レジスタにマップできるハードウェアカウンタの数はプロセッサにより限られているため，数個選ぶ必要がある．
選ぶ際には，以下の3つに注意．
1．正規化の種類(time-based or progress-based)
全てのハードウェアカウンタを両方で正規化し，相関係数が高い値になった方を採用する．
調査の結果，イベントカウント数が関わる値はprogress-based，持続時間が関わる値はtime-basedが適していることが分かった．
2．環境の影響
リクエストを並列に実行した場合の相関係数は，全ハードウェアカウンタの値で低くなっているが，その中でもなるべく影響を受けないもの(*)を採用する．(L2Refferenceなど)
*L2キャッシュ・メモリアクセスに関わる値は，コンテキストスイッチの影響を大きく受けるため，避けたい
*L1キャッシュ・トレースキャッシュ・TLBのイベント関連は，ハイパースレッディングの機能を持つ場合に，これらの機能を共有するために不安定な値をとるため，避けたい
3．アプリケーションによる違い
サーバアプリケーションの種類によって効果のあるハードウェアカウンタが異なるため，それぞれのアプリケーションごとに適切なハードウェアカウンタを選ぶ必要がある．
●値の収集とリクエスト識別●
1．ハードウェアカウンタの値はインクリメントされるため，定期的に値を取り出し，その差を収集する．
2．収集したいくつかの値をシグネチャとし，そのリクエストのプロパティとの対応表を作成する．
3．対応表の値と実行中のハードウェアカウンタの値の差により，リクエストを識別する．
－リクエスト実行してからある一定時間で識別を行う方法と，対応するリクエストが見つかるまで時間を増やして識別を行う方法の2種類がある．
●実験●
4つのサーバアプリケーションで実験した．
―TPC-C，TPC-H，RUBiS，Index search(最初の3つはCPU-bound, その他はI/O-bound)
CPU使用量，I/Oサイズの予測の正確性を評価したところ，並列実行でも7%,3%,20%,40%と非常に低いミスを実現．
RUBiSやIndexsearchは，初めに同じような経路を辿るために他と比べて識別が難しくなっているが，TPCの2つに関しては，リクエスト実行の非常に早い段階で正確な識別ができている．
●応用例●
1．効果的なスケジューリングの実現
この提案手法を用いてレディータスク内で最も残り時間が短いタスクをキューの先頭にもってくることで(SRPTスケジューリング)，デフォルトのスケジュールに比べ70%以上応答時間の削減に成功した．
2．異例なリクエストの検出
似たリクエストでクラスを作り，リクエストを早期に分類することで，SQLインジェクションなどの異例なリクエストの検出が行えた．
…ちょっとはしょったつもりが，詳しく書きすぎたかもｗ
長いｗ
ハードウェアカウンタの値を用いて実行中のリクエストを早期識別しちゃおう！というスゴイ話．
ゼミでやったので詳しめにまとめ．
(先輩方に色々フォローしてもらって勉強になりました！もっとしっかり読めるようになりたい)
●背景＆問題点●
OSは，実行時のワークロードのプロパティを知ることで，より良いスケジューリングが可能になったり，コストを抑えたNWサービスが可能となる．
しかし，現状では，過去のリクエストからワークロードのプロパティを予測する手法がとられている．
この手法では，入力パターンが多く，実行時の状態が変化するワークロードの予測を当てることは難しい．
●提案●
サーバリクエストを実行中の早い段階で識別し，プロパティを予測しよう．
－プロパティとは：メモリ使用量，CPU使用量，I/O発行量など
この，リクエストの識別は，ハードウェアカウンタの値を数個組み合わせてシグネチャとすることで可能となる．
●ハードウェアカウンタの組み合わせ●
レジスタにマップできるハードウェアカウンタの数はプロセッサにより限られているため，数個選ぶ必要がある．
選ぶ際には，以下の3つに注意．
1．正規化の種類(time-based or progress-based)
全てのハードウェアカウンタを両方で正規化し，相関係数が高い値になった方を採用する．
調査の結果，イベントカウント数が関わる値はprogress-based，持続時間が関わる値はtime-basedが適していることが分かった．
2．環境の影響
リクエストを並列に実行した場合の相関係数は，全ハードウェアカウンタの値で低くなっているが，その中でもなるべく影響を受けないもの(*)を採用する．(L2Refferenceなど)
*L2キャッシュ・メモリアクセスに関わる値は，コンテキストスイッチの影響を大きく受けるため，避けたい
*L1キャッシュ・トレースキャッシュ・TLBのイベント関連は，ハイパースレッディングの機能を持つ場合に，これらの機能を共有するために不安定な値をとるため，避けたい
3．アプリケーションによる違い
サーバアプリケーションの種類によって効果のあるハードウェアカウンタが異なるため，それぞれのアプリケーションごとに適切なハードウェアカウンタを選ぶ必要がある．
●値の収集とリクエスト識別●
1．ハードウェアカウンタの値はインクリメントされるため，定期的に値を取り出し，その差を収集する．
2．収集したいくつかの値をシグネチャとし，そのリクエストのプロパティとの対応表を作成する．
3．対応表の値と実行中のハードウェアカウンタの値の差により，リクエストを識別する．
－リクエスト実行してからある一定時間で識別を行う方法と，対応するリクエストが見つかるまで時間を増やして識別を行う方法の2種類がある．
●実験●
4つのサーバアプリケーションで実験した．
―TPC-C，TPC-H，RUBiS，Index search(最初の3つはCPU-bound, その他はI/O-bound)
CPU使用量，I/Oサイズの予測の正確性を評価したところ，並列実行でも7%,3%,20%,40%と非常に低いミスを実現．
RUBiSやIndexsearchは，初めに同じような経路を辿るために他と比べて識別が難しくなっているが，TPCの2つに関しては，リクエスト実行の非常に早い段階で正確な識別ができている．
●応用例●
1．効果的なスケジューリングの実現
この提案手法を用いてレディータスク内で最も残り時間が短いタスクをキューの先頭にもってくることで(SRPTスケジューリング)，デフォルトのスケジュールに比べ70%以上応答時間の削減に成功した．
2．異例なリクエストの検出
似たリクエストでクラスを作り，リクエストを早期に分類することで，SQLインジェクションなどの異例なリクエストの検出が行えた．
…ちょっとはしょったつもりが，詳しく書きすぎたかもｗ
長いｗ
登録:
投稿 (Atom)
