okkyの日記： 208日問題 8
日記 by
okky
Linux Kernel に208日問題というのが存在した。
SuSE11SP1利用者は被害を食らっている。
今調べたら RHEL6 も範囲に入ってた。2.6.32 ベースだ。
Fedora15,16のユーザーもだが、こちらはそもそも安定したバージョンじゃないと理解しているはず。
とりあえず、http://kenichiokuyama.blogspot.com/2011/12/schedclock-overflow-after-2085-days-in.html に内容は記載した。
年明け以降、面倒な事になりそうだ。
なの？ (スコア:2)
スケジューラでnsオーダが要るとは思えないし、手軽だからと言ってTSCを使うのも理解しがたい。
HPETとかPMタイマだと時間が掛かるからダメとか？
Re:なの？ (スコア:1)
nsオーダーの精度を持つハードウェア時計がある時に、わざわざ精度の悪い2つ目を使う必要性がありません。
miyuriさんは「もうすぐお昼ご飯の時間」という程度のことを知るときに、わざわざ日時計を参照して、計算機の時計から目を背けますか??
「お昼ごはん」を知るのに必要な制度なんて日時計で十分ですよね??
でも、「一番手近にある時計」を参照しますよね? 精度関係なく。それと一緒です。
fjの教祖様
Re:なの？ (スコア:2)
「一番手近にある時計」が結構曲者で、
・より正確な値を得たい場合、事前にcpuid等の命令を実行する必要がある
・halt中はカウントしない(CPUによってはカウントするMSRやパフォーマンスカウンタがある)
・ソフトウェア的に制御を行えない可変クロックによって、実時間とずれる
といった面倒な点があったりするわけで。
それでもなお、汎用OSのスケジューラでTSCを使うのかと。
Re:なの？ (スコア:1)
あぁ、コードを読めば判る事を含めて、いくつも勘違いしていますね。
1) CPUID は求めている。というか TSC は Core ごとに別の値を持っているので、これなしでは役に立たない。
2) TSCはhalt 命令中もカウントする (CPUへのクロック供給を止めない限り、TSC自体はカウントし続けます)
3) 「ソフトウェア的に制御できない可変クロック」というのは厳密には間違いです。制御できます。ただし、
スーパーバイザーモードのプログラムだけがクロックをいつ、いくつからいくつに直したのか、
制御できます。つまり、Applicationは制御不能だが、Kernelは制御可能なんです。
これは 2 とも絡む話で、Coreへのクロック供給の停止は、必ず「それを命じるCore」が存在します。
別の言い方をするとクロック供給の停止前に、Coreは「自分のクロック供給が止まる」事を知っているのです。
そして、クロック供給が再起動した場合には「TSC等を含めたプロセッサの初期化」を行なってから、
kernel サービスへと復帰します。
そして、この程度の演算で済むなら、コア外部にある別リソースを参照するよりもよほど素早く「時刻」を求めることができます。
あぁ、そうだ。ここでいう「時刻」っていうのは「何時何分」と言うアレではありません。Jiffies の高性能版と考えてください。
SMPの中でも配線がタイトなマルチコアCPUにおいては、イベントが厳密に「いつ」起きたのかを管理して、その前後関係の
整合性を維持するのってとても大事なんです。
そして
使わないなら、そもそも、こんなバグは起こりませんよ。
昔の 497日問題 (Windows 95,98等で言う 49.7日問題)と同じです。あの時も大勢の人が言いました。
「起動後何秒経ったのかがわからなくなった程度で、なぜ OS が丸ごとコケるのだ??」
「起動後何日経ったのかは、外部時計があるんだからそれでいいんじゃないのか??」
これらの意見は、
「なぜ、携帯電話の時計などという、数日放置して電池が切れるだけで使い物にならないものを、使う？」
「日時計があれば、正午ぐらいそこそこの精度で分かるだろうに」
と言っているのと同じです。
そりゃ判るでしょうよ。でも携帯を使っている人たちは、毎日充電できていると思い込んでいるので、
携帯電話の時計機能で全部用を済ませるんですよ。で、携帯の電池が切れた時にショックを受けるんです。
なぜそんなものに依存したのか? バグってのはそういうもんです。
バグの有り様に論理的整合性を求めてはいけません。そこにあるのは「心理的整合性」だけです。
fjの教祖様
Re:なの？ (スコア:2)
勘違いしていました、sched_clockは時間を返す関数なのですね、あと、TSCはhalt中もカウントしますね。
(別のカウンタは、haltしていない場合のみカウントするのであって。)
失礼しました。
RHEL5は大丈夫ということか (スコア:1)
RHEL6を業務で使っている所はまだそんなに多くなさそうなので(個人的な感想です)、
慌てて中の人が呼び出される、ということはそう多くないかな。
Re:RHEL5は大丈夫ということか (スコア:1)
それは多分無いと思うのですが、全く調査をせずに
「RHEL6やSuSE11SP1で動いているシステムが突如としてダウンした。
きっとお前らのソフトのせいに違いない! 直せっっ!!!」
と喚く客が出てきそうなのが…
# もちろん、「そのバグのせいだという証拠はどこにあるのか?!」という
# 寝言付きで。
ほら、日本のお客様は「CD-ROMでインストールしたイメージ」からピクリとも upgrade しないから。それは RHだけじゃなく Windows でも…
fjの教祖様
Re:RHEL5は大丈夫ということか (スコア:1)
はてブを追いかけていたのですか、Scientific Linux 6.0/6.1 を使っている所で被害が甚大のようですな。
http://b.hatena.ne.jp/entry/kenichiokuyama.blogspot.com/2011/12/schedc... [hatena.ne.jp]
fjの教祖様