この辺から引用
TLBを経由しないってのがどういうのかちょっと分かりませんが、Linuxカーネルはよく通るコードとそうでないコードの差が激しいという性質があるので、上位2Gに加えて最下位数十Kをカーネル空間として、その最下位に最頻出コードを集めてしまうのはどうでしょうか。
カーネルに処理が移るたびにTLBフラッシュするのはいかにも遅そうだし、
カーネル空間が連続していないと困る処理もあんまり思いつきません。
一番キモの最頻出コードをどうやってよりわけるか。ですが、CELFフォーラム(ん?Fがかぶってるな)で開発された partial XIP においてスケジューラ周りだけコードを別セグメントに分離しておいて、起動時にそのセグメントだけRAMにコピー、残りはROMに置いたまま実行。とすることにより、省RAM、高速起動、速度低下微小を実現しているので、きっと同じことが出来るのではない?
どうでしょ?
SuperH, M32R などは、アドレスの値が実際は小さいことを仮定して、小さい即値であれば命令に落とせるというようなインストラクションセットとメモリモデルとなってます。が、これが kernel が 0x80000000 で動くとなっているので全然生きてない。
MMU の設計ですけど、SuperH, M32R で上半分の空間 0x80000000 を kernel 空間とするのはちょっとどうでしょうか。
kernel 空間は(ユーザ空間とは別の)固定の TLB を経由しないアドレス変換とするのが良いように思います。どうでしょうか。
TLBを経由しないってのがどういうのかちょっと分かりませんが、Linuxカーネルはよく通るコードとそうでないコードの差が激しいという性質があるので、上位2Gに加えて最下位数十Kをカーネル空間として、その最下位に最頻出コードを集めてしまうのはどうでしょうか。
カーネルに処理が移るたびにTLBフラッシュするのはいかにも遅そうだし、
カーネル空間が連続していないと困る処理もあんまり思いつきません。
一番キモの最頻出コードをどうやってよりわけるか。ですが、CELFフォーラム(ん?Fがかぶってるな)で開発された partial XIP においてスケジューラ周りだけコードを別セグメントに分離しておいて、起動時にそのセグメントだけRAMにコピー、残りはROMに置いたまま実行。とすることにより、省RAM、高速起動、速度低下微小を実現しているので、きっと同じことが出来るのではない?
どうでしょ?
コメント
コメント一覧 (2)
<a href= http://www.angelfire.com/deojja/1.html >70944</a>
http://www.angelfire.com/deojja/2.html
革命の日々
<a href= http://cnn.com/ASIANOW/asiaweek/97/1031/newsmap/taiwan.html >Asiaweek</a>
http://www.slipups.com/tree/825.html
革命の日々