キャビネット・ユンゲへの投稿
記事番号00274へのフォローを投稿します。
お名前(ペンネイムで結構ですが必要です)
(
ブラウザに個人情報を覚えさせない)
電子メイルアドレス(必要です)
題名(必要です)
Home Page がある方はリンク希望先の URL を記載して下さい
会議室に載せたい内容を以下へお書き下さい (
HTMLを解釈せずにそのまま表示)
6月11日に、Akitaka HOSOMIさんは書きました。 >物心がついたころには、すでに遅く、ハードウェアは、こともあろうに、 >デバイスという形で、ファイルシステムの中に組み込まれてしまってい >たのだった。 > >そもそも、んなモンの中に押し込めて、十派ひとからげで取りまとめて >しまうことに、かんなり無理があるにも関わらず、そこへ押し込んだ当 >の連中は、統一された操作が美しい、などとヌかしておる。 > >ならば、あのとってつけたような I/O CONTROL とか言う機構は、何ぞ。 >キョ〜〜ビのシステムでは、スマートとは言えんし、不恰好ではないか。 >さらには、とても遅い。 > > > >近頃の OS では、 I/O CONTROL の手続きを経てハードウェアを制御す >ることは、カーネル空間とユーザ空間の行き来となってしまうため、か >なりのオーバーヘッドがある。 > >手持ちのマシンを使って Linux ( Kernel 2.0.36 )で試したところで >は、中身の無い ioctl コール( つまり、デバイスドライバ内では何も >せず、即、リターンする )で、約 1.7 マイクロ秒も、かかる。 > >これは、同一ユーザ空間内の C の空( カラ )関数コールが、 十数ナノ >秒で終わることを考えれば、100 倍近くの時間だ。 > > >さらに、 I/O CONTROL を扱うにしても、入力や出力の区別があって、 >然るべきであるのに、なんと ioctl() 関数自体には、その区別が提供 >されていない。このあたりの融通が利くように自前でなんとかしようと >して、適当にメモリ管理をして ... 、などとモガくと、あっと言う間 >に、 5 〜 6 マイクロ秒を消費してしまう。 > >こうなると、もう、論外、場外、国外退去。マイクロ秒オーダなんての >は、ハエが止まる。 > > > >同じ PC で、手持ちの PCI ボードから 1 バイトをポート入力すると、 > > DOS ( マシン語で直接入力 ) : 約 1.0 マイクロ秒 > Win-NT ( カーネル提供の関数 ) : 約 1.3 マイクロ秒 > Linux ( インライン展開関数 ) : 約 1.4 マイクロ秒 > >といった感じで、一般に遅いとされるポートの入出力の処理においてさ >え、 I/O CONTROL は、充分にオーバーヘッドを生むと、考えられる。 > > > > I/O CONTROL なんぞは、今となっては、先人の知恵というよりも、前 >世紀の遺物、恐竜の化石。で、ユーザ空間に対して、何か、他の、新し >い、今風の機構は、提供されないものだろうか? > >仮称 Direct Interrupt とか、Direct DMA とかさ。 > > Win-NT にせよ、 Linux にせよ、ドライバ書きが、力づくで、メモリ >空間に風穴を開けるぐらいしか手が無い、では、キョ〜ビのカーネル様 >としても、あまりに芸が無い、と思うんだけどなぁ。 > > > > >以下は、参考まで。 > > > Linux の場合は、root 権限があれば、アプリ内で、直接ポート操作も >可能であるが、実測では、 > > inb() .... 約 1.46 〜 1.5 マイクロ秒 > outb() .... 約 1.5 〜 1.65 マイクロ秒 > >であり、カーネルモードのドライバよりも処理は遅くなる。 > > > Win-NT と Linux はカーネル空間内のドライバでポート入力を行った >ものだが、ハードウェアの仮想化( 抽象化 )が Linux よりも幾分進ん >でいると思われる NT の方が、なぜか、成績が良い、というのは、ちと、 >興味深い。
cavin@cavin.co.jp
Last Update: 27 April 2022