From n.nakai ＠ sdy.co.jp Mon Oct 5 09:49:55 2009 From: n.nakai ＠ sdy.co.jp (=?UTF-8?B?5Lit5bGF5oay5LmF?=) Date: Mon, 05 Oct 2009 09:49:55 +0900 Subject: [Ultramonkey-l7-develop 539] Re: =?utf-8?b?RGFpdmTjgajjga7oqbHjgZflkIjjgYTjgavjgaTjgYTjgaY=?= In-Reply-To: References: <4AC62ADA.8010808@sdy.co.jp> Message-ID: <4AC942B3.8060706@sdy.co.jp> 竹林様 中居です。 お世話になっております。 > どのみちドライバやハードウェアのレイヤでは，どのアプリケーションが > 使っているソケットなのかを認識することは出来ませんね． > この場合，シングルプロセス・シングルスレッドのプロセスが使用する場合は > 必ずしもプロセスがいる CPU と同じ CPU にキューの刈り取りが走るとは思えません． > > このあたりも，うまいことやってくれるのでしょうか． これから実装される機能ですので、今現状ではアイデア段階らしいのですが accept(2)のAPIをkernel内部で処理するときに発行したプログラムのCPUと lisning socketを紐付けするのでしょう。 keyがlinsing socketでvalueがCpuIdのMultiMapと言う考え方でよいかと思います。 ネットワークドライバ(もしくはHWは)、上記multimapよりcpuを認識し該当CPUに IRQを上げると言う動きになります。 従って、DirectedAcceptではIRQのピンを刺すわけではなくて積極的にacceptを 発行したCPUにIRQを上げると言う仕組みに変わります。 acceptを発行するthreadが一つだった場合には(=シングルプロセス)、使用する CPUはもちろん一つですからIRQを上げるCPUも一つになり、今まで通りの動きに なると思われます。 ただ、今まではプロセススケジューラがプロセスをIRQがあがるCPUに動かしてい ましたが、DirectedAcceptの場合にはIRQ割り込みがプロセスの動いている (Acceptを発行した)CPUにあがる、と言う違いはあるでしょうか。 > 既存の accept に頼らない方式を模索するのか，それとも既存の accept を > リファインするのかといったところでしょうか． accept(2)自体の変更は存在しないかなとも思いますが。 形自体はSUSv2準拠ですし。 > accept して fork して・・・というモデルが，そもそも fork した状態の > プロセスが accept を走らせるような構造になるんですね． ですです! threadだとacceptしてpthread_create(2)してthreadにscoketを引き渡していた と言う作りがpthread_create(2)してaccept(2)を発行する形になるかと思います。 > APR あたりが特に大きな影響を受けそうです． > DBMS も地味に痛いかもしれません． このあたりは順次変更されていくかと思いますが、 シングルスレッドの場合には影響が少ないので、 「対応出来るものだけ速くなる」といった感じでしょうか。 >> 一応リクエストとしては21日か22日と言う日程を提示しておきました。 >> それまでに資料を再度追加もしくは変更したいです。 >> …がんがりますorz > 可能な限りお手伝いさせてください． > よろしくお願いいたします． すいません、ユーザー空間アプリケーション構造について、煮詰めておきたいで すよね。 上記作りを中居が聞いた限りでは、thread poolの実装がそのまま方式に結びつ くと言うメリットを発見しました。 また、DirectedAcceptは絶対CPUをMaskしないのか?と言う疑問もあります。 と、言うのもGoogleが開発しているRPSはCPUMaskと言う設定が/procに出ています。 一つのCPUを占有したいようなシステムの場合、そのCPUに割り込みがあがるのは やっかいなことなのでMaskして割り込みを外したい場合が存在するかもしれません。 その場合にはアプリ側で割り込まれないCPUに対してthreadを用意するのはメモ リの無駄になりますから、事前に割り込みのMaskされるCPUは(/procでもかまわ ないので)通知してほしいかと。 このmaskは現状のdirected acceptに存在しないのはフェルナンドさんに聞いて わかっていますが、リクエストとしてmaskが入りそうな気がします。 …このような感じで実際的にアプリケーション構造の意識あわせから、 Davidさんとの会合で質問できるリストなどがあればイイかな?とも思います。 どうぞよろしくお願いしますm(_ _)m -- _____________________________________________ 中居 憲久[Norihisa NAKAI] n.nakai ＠ sdy.co.jp 株式会社SDY tel:047-401-7210/fax:047-401-7207 From h-nakano ＠ iwao.net Mon Oct 5 15:45:35 2009 From: h-nakano ＠ iwao.net (Hiroaki Nakano) Date: Mon, 05 Oct 2009 15:45:35 +0900 Subject: [Ultramonkey-l7-develop 540] Re: =?iso-2022-jp?b?RGFpdmQbJEIkSCROT0MkNzlnJCQkSyREJCQkRhsoQg==?= In-Reply-To: <4AC942B3.8060706@sdy.co.jp> References: <4AC62ADA.8010808@sdy.co.jp> <4AC942B3.8060706@sdy.co.jp> Message-ID: <4AC9960F.5000000@iwao.net> 中野%tarusoopyです。 # 家からだし、仕事でない範囲なのでtarusoopyモードｗ 中居憲久 さんは書きました: > 竹林様 > > 中居です。 > お世話になっております。 > > >> どのみちドライバやハードウェアのレイヤでは，どのアプリケーションが >> 使っているソケットなのかを認識することは出来ませんね． >> この場合，シングルプロセス・シングルスレッドのプロセスが使用する場合は >> 必ずしもプロセスがいる CPU と同じ CPU にキューの刈り取りが走るとは思えません． >> >> このあたりも，うまいことやってくれるのでしょうか． > > これから実装される機能ですので、今現状ではアイデア段階らしいのですが > accept(2)のAPIをkernel内部で処理するときに発行したプログラムのCPUと > lisning socketを紐付けするのでしょう。 > keyがlinsing socketでvalueがCpuIdのMultiMapと言う考え方でよいかと思います。 > ネットワークドライバ(もしくはHWは)、上記multimapよりcpuを認識し該当CPUに > IRQを上げると言う動きになります。 > 従って、DirectedAcceptではIRQのピンを刺すわけではなくて積極的にacceptを > 発行したCPUにIRQを上げると言う仕組みに変わります。 > > acceptを発行するthreadが一つだった場合には(=シングルプロセス)、使用する > CPUはもちろん一つですからIRQを上げるCPUも一つになり、今まで通りの動きに > なると思われます。 > ただ、今まではプロセススケジューラがプロセスをIRQがあがるCPUに動かしてい > ましたが、DirectedAcceptの場合にはIRQ割り込みがプロセスの動いている > (Acceptを発行した)CPUにあがる、と言う違いはあるでしょうか。 普通にfdのacceptに対してNAPIは刈り取りするだけですな。 アプリケーションがMQを意識して複数スレッドでacceptしていれば自動で 処理CPUが動かないように処理してくれるし、シングルスレッドな アプリでCPUが違っていたり、MQ意識していないアプリなら これまでどおり別CPUで処理しようとして遅くなるだけです。 ・・・というふうに作るつもりだと思われますｗ 自分でもそう作ります。 # 本気出した世界中のハカー達の開発スピードには到底 # 追いつけませんでした(ノД｀) >> 既存の accept に頼らない方式を模索するのか，それとも既存の accept を >> リファインするのかといったところでしょうか． > > accept(2)自体の変更は存在しないかなとも思いますが。 > 形自体はSUSv2準拠ですし。 変更無いと思います。 もし変更が必要となるもの(必要な引数が足りない、とか)に気づいたら、 カーネルサミットもしくは個別会談までに提示をお願いします。 >> accept して fork して・・・というモデルが，そもそも fork した状態の >> プロセスが accept を走らせるような構造になるんですね． > > ですです! > threadだとacceptしてpthread_create(2)してthreadにscoketを引き渡していた > と言う作りがpthread_create(2)してaccept(2)を発行する形になるかと思います。 そういうプログラムになりますね。 >> APR あたりが特に大きな影響を受けそうです． >> DBMS も地味に痛いかもしれません． > > このあたりは順次変更されていくかと思いますが、 > シングルスレッドの場合には影響が少ないので、 > 「対応出来るものだけ速くなる」といった感じでしょうか。 カーネル開発者側としては、「アプリ開発者が対応したければすれば」って 感じになるかとｗ CELFでもディスカッションで出てましたが、「システムコールとかの 使い方みたいなドキュメントが欲しい」って感じですかね。 API仕様書だけでなく、こうすると速くなる！とか、こうすると駄目駄目だ！ なんてシステムコールの使い方がわかるような資料が欲しいって 要望が出てました。 >>> 一応リクエストとしては21日か22日と言う日程を提示しておきました。 >>> それまでに資料を再度追加もしくは変更したいです。 >>> …がんがりますorz >> 可能な限りお手伝いさせてください． >> よろしくお願いいたします． > > すいません、ユーザー空間アプリケーション構造について、煮詰めておきたいで > すよね。 > 上記作りを中居が聞いた限りでは、thread poolの実装がそのまま方式に結びつ > くと言うメリットを発見しました。 > > また、DirectedAcceptは絶対CPUをMaskしないのか?と言う疑問もあります。 > と、言うのもGoogleが開発しているRPSはCPUMaskと言う設定が/procに出ています。 > 一つのCPUを占有したいようなシステムの場合、そのCPUに割り込みがあがるのは > やっかいなことなのでMaskして割り込みを外したい場合が存在するかもしれません。 > その場合にはアプリ側で割り込まれないCPUに対してthreadを用意するのはメモ > リの無駄になりますから、事前に割り込みのMaskされるCPUは(/procでもかまわ > ないので)通知してほしいかと。 maskとかはあってもいいかもですね。 Direct FlowやDirect Acceptに対応していないカード、ドライバだとまた アプリの作りに影響はするんですが、そこはカーネル側でDirect Acceptを ソフト的にエミュレートしたほうがいい気がします。 Direct Acceptの提唱者も未対応ハードには擬似コードでなんとかしたいと 思っているようです。 > このmaskは現状のdirected acceptに存在しないのはフェルナンドさんに聞いて > わかっていますが、リクエストとしてmaskが入りそうな気がします。 > > …このような感じで実際的にアプリケーション構造の意識あわせから、 > Davidさんとの会合で質問できるリストなどがあればイイかな?とも思います。 > > > どうぞよろしくお願いしますm(_ _)m > >