From makoto @ kanon-net.jp Sun Oct 4 22:20:08 2009 From: makoto @ kanon-net.jp (makoto @ kanon-net.jp) Date: Sun, 04 Oct 2009 22:20:08 +0900 Subject: [Ultramonkey-l7-develop 538] Re: =?iso-2022-jp?b?RGFpdmQbJEIkSCROT0MkNzlnJCQkSyREJCQkRhsoQg==?= In-Reply-To: <4AC62ADA.8010808@sdy.co.jp> References: <4AC62ADA.8010808@sdy.co.jp> Message-ID: 竹林です. 色々とお任せしてしまい,すみません. > このDirected AcceptはFlowDirectorの拡張で、アプリケーション側からは複数 > のthreadからacceptを同時に発行し、HWもしくはドライバはバランシングを行っ > て空いているCPUにMQの割り込みを上げて、そのCPUに結びついているacceptに反 > 応を上げると言う機能です。 > > このDirectedAcceptのメリットは、HWもしくはドライバが能動的に動くためソフ > トウェア側からは複数同時にacceptを発行するコードにすれば、どのQueueを使 > うのかと言う意識を行う必要がないと言うことですね。 > > kernelはユーザー空間のacceptを受けたときにそのthreadが所属するCPUを知る > ことが出来るため反応させるacceptを選択することで自動的にqueueのCPUと、処 > 理するユーザー空間のthreadのCPUがあうと言うことですね。 どのみちドライバやハードウェアのレイヤでは,どのアプリケーションが 使っているソケットなのかを認識することは出来ませんね. この場合,シングルプロセス・シングルスレッドのプロセスが使用する場合は 必ずしもプロセスがいる CPU と同じ CPU にキューの刈り取りが走るとは思えません. このあたりも,うまいことやってくれるのでしょうか. > ただ、それでも現在accept(2)は内部でシリアライズされるため、acceptを複数 > 発行してもブロックされる実装のため複数同時acceptの構造にはなっていません。 > プログラム的構造はかなり変化があると言えます。 > (select/epollな実装はもちろん、accept threadが処理threadに処理を委任する > 今一般的に実装されているserver thread modelは変化を求められるとも言えます) 既存の accept に頼らない方式を模索するのか,それとも既存の accept を リファインするのかといったところでしょうか. accept して fork して・・・というモデルが,そもそも fork した状態の プロセスが accept を走らせるような構造になるんですね. APR あたりが特に大きな影響を受けそうです. DBMS も地味に痛いかもしれません. > つまり現状中居がSFJにupしている資料は古くなっているのでUPDATEが必要です > ね。DirectedAcceptに対応した方式を提示するとともに、どのような話し合いを > 行うか、全員の理解と意識あわせをしたいですね。 > > 一応リクエストとしては21日か22日と言う日程を提示しておきました。 > それまでに資料を再度追加もしくは変更したいです。 > …がんがりますorz 可能な限りお手伝いさせてください. よろしくお願いいたします. ---------------------------------------------------------------- Shinya TAKEBAYASHI E-mail : makoto @ kanon-net.jp GPG ID : FFD20D1F GPG FP : 7B5B E0FC B785 7457 683C 47D6 5564 DDDD FFD2 0D1F ----------------------------------------------------------------