Hajime Okada
h.oka****@sdy*****
2009年 8月 25日 (火) 13:42:21 JST
UltraMonkey-L7
Fork岡田です。
> ところで，カーネルの話とユーザ空間の実装の話がごっちゃになって
> きていますので，いったんスレッドを分けましょうか．
このメールはユーザ空間の話がメインですね。
>> あと、上記リンクの中の下の図で、受信スレッドと送信スレッドが別のCPUで動いていま
> すが、
>> コア間のデータのやり取りを減らすため、送信スレッドが動くCPUと送信スレッドが動く
> CPUを同じにできれば、速度を追求できるのではないでしょうか？
> これは，ひとつの FD に対して，送信キューと受信キューが別の CPU のものに
> 割り当てられるという可能性がある，ということでしょうか．
すいません、間違った事を書いてました。
送信スレッド・受信スレッドでなく、CL側スレッド・RS側スレッドです。
> 竹林の認識では，IP アドレスやポート番号，MAC アドレスなどで
> セッションごとにキュー（CPU）が変わることはあったとしても，
> ひとつのセッションのなかの送受信で別の CPU を使うようなことはないと
> 理解しています．
1つのセッションの中でキューが変わることはないですね。
> 図の中では，スレッドの関係は
>
> ・Listner
> ・Clients-side
> ・Realservers-side
>
> の 3 つから成り立つと仮定しているので，リアルサーバが scheduler で
> 決まった後，リアルサーバに接続しにいくにあたって一番コストが小さい
> キューを選んでそのスレッドプールのスレッドを使うだけで良いと思います．
>
> 従って・・・
>
>>> - ハッシュ関数のインタフェイス
>>> → リアルサーバに一番近い
>>> どんな情報が必要かも含む．
>> ？？？
>> すいません、ここがちょっとわからないです。
>
> 失礼しました．文が途中で切れてしまいました．
>
> 言いたいことは，リアルサーバへ繋ぎに行くに当たって使うべき
> キューを知るためのインタフェイスを用意する必要がある，ということです．
なるほど納得です。
RS側のスレッドも、キューが割当たるCPUの情報を取得してそれを使う方法ですね。
「送信時のキューをユーザから設定できる」は、CL側スレッドとRS側スレッドでデータを共有するケースなどで、NUMAノードをまたいだメモリアクセスだとhopが発生するケースを押さえる目的で言っています。
正しくは「RS側スレッドが使用するキューをユーザ空間から設定できる」ですが・・・。
※ただし、データサイズ的にAtomicには成らないでしょうから、hopよりもロックのコストが大きいでしょうね・・・。
意味なしですね・・・。
よろしくお願いします。
--
/*========================
H.Okada / 岡田 創
h.oka****@sdy*****
株式会社SDY
========================*/