川辺と申します。 # ちょっと時間が空いてしまいました。SPARCのアセンブラと戯れているもので、.... >>>>> "Naoto" == Naoto Shimazaki <igy@xxxxxxxx> writes: Naoto> 読みたくない人はとっくにフィルタしてると思われ。 ですね。 Naoto> つーか、「Linux のデバドラ書いて ROM にねじこんで」なんていう Naoto> 話題は Linux user の activity に他ならないと思いますから、 Naoto> よろしいのではないかと。 確かにおっしゃる通りですね。 Naoto> 私は去年 ARM 系 CPU のボード用にデバドラを書いたのですが、まあ、 Naoto> いろいろとなんだなあという所に直面する事たびたび。 ARMですか。(仕事で)いじりそうになって頓挫したので、日本法人からせっか く買ったCPUのリファレンスマニュアルが背後で泣いています。CPU的には、多 くの命令が条件実行の命令になってたり、16bitのThumb(でしたっけ)命令とか 面白そうだとは思ってるんですが。機会が無くて .... # Zaurusでも買って遊べばいいんじゃないかと言う話はあるのですが。 Naoto> http://www.netbsd.org/Documentation/kernel/uvm.html ふむふむ。後で読ませてもらいます。 Naoto> まだこのスレッドを読んでいるかもしれない榎田さんや Naoto> もしかすると読んでいるかも知れないその他の不特定の Naoto> 人々を念頭に置いた記述ですので、どうぞお気になさらず。 了解です。話題が深くなってきたのでつい読者を忘れてしまってました。 Naoto> 問題点が指摘されていました。そのころから 2.4 までデバドラの 指摘されてたのに、放置だったんですね。うーん、こりゃずっと変わらないで すね。おそらく、かなりかっとんだモデルを新たに導入なんてことにならない 限りいじられることは無さそうですね。 Naoto> なんとなく、設計ミスじゃないかという気がします。 ですよねぇ。 Naoto> 上にも書きましたが、幅広いコンテキストで呼ばれるルーチンが Naoto> 割り込み状態の保存and禁止と復帰を対で扱うのは必然です。 はい。 Naoto> 必要がありません。前者は許されないからです。プログラマに Naoto> 必要のない選択を要求しないのは、良い設計です。 ハゲシク同意です。 Naoto> しかし Linux はそうなっていない。 そうなんですよね。ちょっと驚きます。 Naoto> 「以前の状態への復帰」のコストが大きいと性能にひびきます。 それは、昔(と言ってもせいぜい、386/486でしょうか)の x86 の pushf の問 題ですかね。 Naoto> コストは実際非常に小さく済みます。CPU のレジスタか、 Naoto> せいぜい 1 次キャッシュくらいまでしか消費しません。 RISC系なら、よほど間に処理が挟まらなければ、レジスタに載せたままですよ ね。ですから、汎用レジスタと制御レジスタの間の操作ですね。 move to flag|control registre とかの命令ですから、レジスタ間の演算の数倍で収ま ると思います。(レイテンシとして。スループットではほとんど変わらないか もしれないですね。) Naoto> 私には理由は分かりません。 うーん、そうですか。 今となっては、Linuxのカーネルソースって、興味のあるプログラマがカーネ ルを勉強するときのリファレンスに使われる可能性が高いですよね。もちろん、 そういうことには、BSD系の方が向いていると思いますが。(憶測ですが) そういう時に、あのやり方が普通(正しい、常識、...)とか思われると嫌です ね。 Naoto> アクセスするとはっきりと性能に影響します。そこで、「本当に Naoto> 割り込まれるまでは割り込みをマスクしたフリをする。割り込まれて Naoto> から改めて割り込みコントローラを操作してちゃんとマスクする。」 なるほど、割り込みエントリで割り込みのディスパッチ(実際のドライバの割 り込みルーチンの呼び出し)をスケジューリングする様な感じでしょうか。 ちょっと素朴な疑問なのですが、いわゆるレベル型の割り込み信号はいいんで すが、エッジ型の割り込み信号みたいなのの場合って、割り込まれたことを記 録しておくって感じですか? あぁ、でも、これは、チップレベルのことだから関係無いのかな。割り込みコ ントローラがよしなにはからってくれればいいんだろうな。 Naoto> なんてことをやります。非常に I/O の忙しい環境下では 20% 位 Naoto> 性能に影響したりしますから侮れません。 実際のパーセンテージは状況依存でしょうが、確かに割り込みコントローラへ のアクセスが入るか入らないかはその部分のレイテンシが桁違いに変わります よね。今時のCPUクロックと他チップアクセスのクロックが10倍近く違う状況 では、実際に数十倍の差は出そうですね。で、その結果、全体で 20% の違い が出ることがある、となったらとんでも無いレベルでの性能向上になりますね。 CPUの中にあった、MC68Kシリーズが懐かしいな。(いや、これがいいと言う意 味ではなく) -- Kawabe,Yoshihiro <ripula@xxxxxxxxxxxxxxx> As the stars blink in the night sky, our married hearts are never splitted. Even if we will unclasp each other hands, until we retain that. by H.S.
Follow-Ups:
- [linux-users:102337] Re: 組込Linuxドライバの作成方法Naoto Shimazaki
- [linux-users:102241] Re: 組込Linuxドライバの作成方法Naoto Shimazaki
- [linux-users:102250] Re: 組込Linuxドライバの作成方法Yoshihiro Kawabe
- [linux-users:102289] Re: 組込Linuxドライバの作成方法Naoto Shimazaki
- Prev by Subject: [linux-users:102304] swatchについて
- Next by Subject: [linux-users:102306] Re: 組込Linuxドライバの作成方法
- Previous by thread: [linux-users:102325] Re: 組込Linuxドライバの作成方法
- Next by thread: [linux-users:102337] Re: 組込Linuxドライバの作成方法
- Indexes:[Main][Thread]