- ベストアンサー
usleepの大幅遅延、スケジューラ周りの問題？
- usleep(10000=10msec)をしてはgettimeofdayで時刻を確認するだけという、小さなプログラムを例えば４つ同時に走らせます。すると、バッググラウンドで何かが起こった際か、あるいは自分で意図的にファイルコピーとsyncを実施した際などに、10msecよりも大幅に待たされるプロセスが発生して困っています。具体的には、130～180msec程度の時間で、ファイルコピーをした際の1/2回ほどぼ頻度で、殆どのケースで4つのうち1プロセスのみ大幅に待たされます。
- vmstatを見る限り、どうやらcpuのwaか、ioのboが増大し、それと同時期に遅延が生じ易いように見えます。しかし、CPUの速度や、IOの速度そのものは、遅延が起こるほど遅いものではありません。他の同程度か遅いPCにおいては問題は起こっておらず、ある特定のPC環境でのみ起こってしまっています。
- 使っているPCはちょっと特殊で、本来はAndroid等が動く、小型で非力なARM系のもの(MK808というPCに、PicUntuというOS)なのですが、そちらではあまり情報が見つけられず、Linux全般の話題としてどういったことが想像されるか、御存知の方に御意見をいただきたく質問をさせていただきました。
- みんなの回答 （4）
- 専門家の回答
質問者が選んだベストアンサー
>しかし、ハードウェアの全体的な性能を考えると、経験的に、10msecのスリープに対し、130～180msecの時間が経過するというのは(低い負荷の範囲において)異常なほど長いと認識しております。 それはたんに今まで経験したことなかったというだけの話でしょう。 >よって、カーネルを構成する際のコンフィグや、例えばARM用あるいは特定のハードウェア用にコンパイルされたカーネルでは、○○の理由によりこういった問題が起こるといった情報が得られればと期待して質問をさせていただいた次第です。 MK808またはROCKCHIP RK3066での話ということになると思いますので、Okwaveなどで情報を得るのは少々厳しい気がします。 仮に自分で調べるとしたらカーネルを含めプロファイルを取ってみるとかになるかと思います(具体的な方法などは聞かないでください)。 もしくはusleepではなくselectやnanosleepを使ってみるとか。 PicUntu開発メンバやROCKCHIP社に問い合わせてみるという手もなくはないでしょうが。
その他の回答 (3)
- wormhole
- ベストアンサー率28% (1626/5665)
>もし御存知のことがありましたら、お力添えをいただければありがたく存じます。 とりあえずいえることはusleep(sleepもだけど)は少なくとも指定した時間分はそのプロセスは停止しますが、それより長く停止することはありえます。man 3 usleepにも書いてあります。 なのでusleep(10000)は「10msecプロセスをスリープする」ではなく「最低10msecプロセスをスリープする」と考えるべきです。
補足
ありがとうございます。それについては存じております。 しかし、ハードウェアの全体的な性能を考えると、経験的に、10msecのスリープに対し、130～180msecの時間が経過するというのは(低い負荷の範囲において)異常なほど長いと認識しております。十分に早いx86系のノートPCでは20msecを超えることはまず無いでしょうし、ラズベリーパイでも同様のテストでも頑張って負荷を掛けて30msecという程度でした。 よって、カーネルを構成する際のコンフィグや、例えばARM用あるいは特定のハードウェア用にコンパイルされたカーネルでは、○○の理由によりこういった問題が起こるといった情報が得られればと期待して質問をさせていただいた次第です。
- wormhole
- ベストアンサー率28% (1626/5665)
>ラズベリーパイがより非力なARM系のPCなので試したところ、上記ほど大幅に遅れるということはありませんでした。 カーネルやハードウェア構成が変わると事情が変わりけど・・・ 非力＝マルチタスクが苦手, タイマーの精度が悪い というわけじゃありませんから。
補足
回答くださり、ありがとうございます。 No.1の非力なARMでの精度を調べる、ということについて、 どういった調べ方をすれば良いでしょうか？ usleepの精度が悪いというのは、10msecという指定に対して、稀に180msecも寝たままというのは精度が悪いというレベルを逸脱しているように思いましたので、どういった観点から精度を確認すれば良いか分かっていない次第です。 gettimeofdayの精度という側につきましては、これが「実際にはsleepは10msecにも関わらず、取得した時刻情報にずれがある」といった類ではないことまでは確認しています。 実際には、本PCと別のデバイスとで定期的な通信を行うのですが、このsleepが長くなったのと同時に、デバイス側より、定期通信が規定時間内に得られなかったという信号が出ています。 もし御存知のことがありましたら、お力添えをいただければありがたく存じます。
- wormhole
- ベストアンサー率28% (1626/5665)
なんとなくですが、usleepやgettimeofdayの精度の方の問題な気がします。 kernelのそれらに関係するARM用の実装がどうなってるのか調べてみてはどうでしょうか。 また関連してその非力なARMでそれだけの精度が出せるのかも調べた方がいいのかもしれません。
補足
補足をさせていただきます。 ラズベリーパイがより非力なARM系のPCなので試したところ、上記ほど大幅に遅れるということはありませんでした。
お礼
> それはたんに今まで経験したことなかったというだけの話でしょう。 その通りですが、ハードウェアの性能と、これまでLinuxを使用した経験から鑑みると、という意味にございます。 私がLinuxのカーネルやその他基礎部分までは詳しく無いので、質問をさせていただきましたが、回答を得づらい質問だということですね。 「カーネルを含めプロファイルを取ってみる」「selectやnanosleep」を試してみてから、別の場所での問い合わせを実施してみます。 お付き合いをいただき、ありがとうございました。