Shinya TAKEBAYASHI
makot****@kanon*****
2009年 8月 21日 (金) 23:54:32 JST
UltraMonkey-L7
Fork竹林です．
> >> 方式的には「CPUに結びついたThreadPoolを持つ」のが特色でしょうか。
> > 論理 CPU の数だけスレッドプールを作って，各々のスレッドプールに
> > 各ソケットを処理するスレッドをプーリングする，という思想で良いでしょうか．
> > sched_setaffinity に tid と mask を渡して，擬似的に
> > スレッドプールを作るような・・・．
>
> 擬似的ではないですね。
> これはsched_setaffity()を発行してthread所属のCPUをその都度移動すると
> コストが非常にかかるため、最初にCPUごとにThreadPoolを作成する必要があり
> ます。
> (どれぐらいコストがかかるかは測定していません…)
意図していることは，中居さんの言うとおりです．
表現が曖昧でした．すみません．
> > ・コネクションの処理にあたって必要な情報
> >
> > - FD に紐付いた CPU
> > → FD を握っている CPU が持つスレッドプールを特定するために必要．
> >
> > - Queue 割り付けのハッシュ
> > → リアルサーバ通信用スレッドを起こすためにスレッドプールを
> > 特定するために必要．
>
> このあたり難しいのですが、RPSにしろMQにしろ必要なのはCPUMaskです。
> そして、CPUMaskを得るための情報は
> ・FD
> ・sockaddr_strage
> ・MACアドレス
> ・etc...
> と、存在します。
これはユーザ空間から渡してあげる情報ですね．
まずは何が欲しいかを洗う必要がありますので，
1. 何が欲しいか
→ CPU mask 値
2. 現状では何が取ってこれるか
→ ？？？
3. もし 2 に 1 を含まないのであれば，2 は 1 の代替として使えるものか
→ y/n？
3.x 代替できなければ，新しいインタフェイスやデータ型をつくる
→ ？？？
4. 取ってくるために与える情報は何か
→ FD，MAC アドレス，et.,al.
の順に検討していく方が良いかと思います．
> > 方式の面では，先日話したように，起動時にのみ必要な情報は sysfs などで，
> > コネクション処理で必要な情報については ioctl などで取ってくるように
> > した方が良いかもしれません．
> > ＃ sockaddr_storage を内包する構造を新しく定義するとか必要？
>
> ioctlもしくは新しいAPIになるかと思います。
> sysfsを開くにはOpenしてreadしてテキストをパースして…と重たい処理が続きます。
> それがコネクションが発生するごとに行うのは流石にオーバーコストかと思います。
えぇ，文字列解析がネックになりますし，いちいち sysfs に
吐き出させるためのコストも馬鹿にならないと思います．
お行儀を考えた場合でも，ほぼ静的な値は sysfs に，動的な値は都度，
何らかの軽いインタフェイスで取ってくるのが良いと思います．
パフォーマンス比較のために，ダメもとでサンプルを書いてみても
良いかもしれません．
----------------------------------------------------------------
Shinya TAKEBAYASHI
E-mail(private)： makot****@kanon*****
GPG ID : FFD20D1F
GPG FP : 7B5B E0FC B785 7457 683C 47D6 5564 DDDD FFD2 0D1F
----------------------------------------------------------------