トップ «前の日記(2007年04月02日) 最新 次の日記(2007年04月04日)» 編集
2003|01|02|03|04|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|10|12|
2009|02|03|06|07|10|11|12|
2010|01|02|03|04|07|09|10|11|12|
2011|01|03|04|05|06|07|08|10|
2012|01|06|08|09|10|12|
2013|01|02|03|04|07|09|11|12|
2014|01|03|04|05|06|09|
2015|04|
2016|01|08|
ここは旧えびめもです。えびめも2に移行します(2016/12/1)

2007年04月03日

usleepの話

昨日の実験で usleep(1) は 2jiffy寝ると書いた。次に「Diskに対するFile I/O で -o sync オプションをつけてマウントしていたら、たとえ1バイトの書き込みでも2jiffy待たされる」と書いたけれど、これは正確性にかけると思われる。

usleep(1)の場合は
・現在時刻を1tickに切り上げる(ここで1tick)
・1usec先(をtickに切り上げる)にソフトウェアタイマーを仕掛ける(合計2tick未来時刻)
・寝る
というロジックであれば予測どおりになるのだが、Diskの方はDiskからの割り込み契機で TASK_RUNNING に戻るので、その次の schedule()の呼び出しで起床されるチャンスは十分にある。具体的にいうとDiskの割り込みによって呼ばれた entry.S の戻りパスである。よって追試が必要になった。

CFへのファイルライト実験結果

条件
     プラットフォーム CAT709  (SH3 117MHz)
     FAT フォーマットされた CF を -o sync オプション付きでマウントする
     HZ は 100
結果
     write(fd, &dummy, 1)  1バイトライト
     の平均時間は 3.41 msec
sync付きだと書き込みバッファキャッシュを無効にするのでwrite()は書き込みが終わるまで待機してから抜けてくる。SH3 CPU速度にひきずられているのではなく、CFのアクセスタイムに引きずられていると思われるが、とにかくも20msecかかるということはなかった。