中居憲久
n.nak****@sdy*****
2009年 10月 3日 (土) 01:31:22 JST
TO:竹林様 CC:中野様 CC:フェルナンド様 本日ceLinux Technical JamboreeでフェルナンドさんとLinuxNetworkのお話をし ました。 (ceLinux Technical Jamboree後で場所を貸してもらってありがとうございま す、SONYの上田さんってカンジで) Fernandoさんが先日portlandで行われたLinuxCon2009でkeynote sessionで(!)MQ の実装の話が出てきたそうで、Linuxの中でMQの重要性がうかがい知れます。 そこでの新情報として、David S.Millerさん等はDirected Acceptを実装仕様と していると言うお話を伺いました。 このDirected AcceptはFlowDirectorの拡張で、アプリケーション側からは複数 のthreadからacceptを同時に発行し、HWもしくはドライバはバランシングを行っ て空いているCPUにMQの割り込みを上げて、そのCPUに結びついているacceptに反 応を上げると言う機能です。 このDirectedAcceptのメリットは、HWもしくはドライバが能動的に動くためソフ トウェア側からは複数同時にacceptを発行するコードにすれば、どのQueueを使 うのかと言う意識を行う必要がないと言うことですね。 kernelはユーザー空間のacceptを受けたときにそのthreadが所属するCPUを知る ことが出来るため反応させるacceptを選択することで自動的にqueueのCPUと、処 理するユーザー空間のthreadのCPUがあうと言うことですね。 これは非常に合理的な話であって、正直「その手があったか!」と言う感じです。 また、この方式にはメリットがあって、1CPUにn個のthreadをacceptさせること で、たった一つのthreadのacceptが反応する…この動作はthread pool以外の何者 でもありません。 acceptでblockしているthreadを終了させるときにはacceptしているFDをcloseす ればhangupがすべてのacceptに通知されると言うことで、動作的にも素直な動作 になります。 #送信側はFlowDirectorで自動的にQueueを選択してくれます。 ただ、それでも現在accept(2)は内部でシリアライズされるため、acceptを複数 発行してもブロックされる実装のため複数同時acceptの構造にはなっていません。 プログラム的構造はかなり変化があると言えます。 (select/epollな実装はもちろん、accept threadが処理threadに処理を委任する 今一般的に実装されているserver thread modelは変化を求められるとも言えます) よって、JLSの時にこの構造に対して実装的話し合いをDavid.S Millerさんとす ることになるかと思いますが、この部分に関してどのようなアプローチがユー ザー空間側のコードとして有効なのか、ユーザー空間側のアプリケーションとし て必要な者は何があるのかという部分をまとめる必要があると思います。 #時間的にぎりぎりになっていますけれど つまり現状中居がSFJにupしている資料は古くなっているのでUPDATEが必要です ね。DirectedAcceptに対応した方式を提示するとともに、どのような話し合いを 行うか、全員の理解と意識あわせをしたいですね。 一応リクエストとしては21日か22日と言う日程を提示しておきました。 それまでに資料を再度追加もしくは変更したいです。 …がんがりますorz p.s. 2004年のLinux Kernel Conferenceで中野さんがお会いしたのはDavid S.Miller さんですねw http://itpro.nikkeibp.co.jp/free/ITPro/NEWS/20041015/151304/ -- -------- 中居 憲久 n.nak****@sdy***** 株式会社SDY http://sdy.co.jp
UltraMonkey-L7
Fork