Windows KernelのThread Scheduling備忘録

process contextの切り替えはthread contextの切り替えよりオーバーヘッドが大きい。しかしthread schedulingはthreadがどのprocessに所属しているかと関係なく行われる。ということは同じ優先順位のprocessがそれぞれ3個づつのthreadを持っていた場合に，最低1回で済むprocess context切り替えが，無差別にscheduleすると最悪5回も起こってしまう。
実際はそれぞれのプロセスで優先順位が違う場合が多いし，優先順位が同じthreadは近いところでスケジュールされるので，同じprocessに所属していることで結果的に近いところでスケジュールされるのかも知れない。レアケースを意識して下手にschedulerを複雑にすると，却って確実にscheduling overheadが大きくなってしまう。
ただ，SMTやSMP，NUMAの場合は，同じprocessに所属するthreadを同じCPUに割り当てた方がキャッシュの使い回し等を考えると明らかに効率的である。この場合，アプリケーション側で明示的にAffinity Maskを指定することもできるが，Ideal Processor CPUIDとLast Processor CPUがkernel thread blockに含まれているので，同じCPUにbindすべきthreadが同じIdeal Processor CPUIDを持つようにすれば，schedulerはIdeal Processor / Last Processorを考えてscheduleするのかなぁ，と思ったんだけど，"Inside Windows 2000"(上) p.376をみると「アイディールプロセッサは、スレッドが作成されたときに、プロセスブロック内のシードに基づいてランダムに選択される」とかかれているので，Ideal Processor / Last Processorは，同じプロセスに所属するプロセスを同じCPUに寄せることを考えてつくった仕組みではなさそうだ。よくよく考えてみるとWindows 2000はSMTやNUMAが流行る前に書かれているので，これらを意識していない可能性も高い。
個人的には最初からIdeal Processorなんていわずにkernel thread構造体にprocess idを突っ込んでしまって，それをある程度意識した方が，前述の問題も一緒に解決できていいような気がするのだけれども，どんな問題があるのだろうか。あー，はやく"Inside Windows 2003"とか出ないかなぁ。この手の話，Linuxならググってkernel-mlの過去ログを追っかけるだけでいいんですけど....