NetBSD UVM page coloringメモ
カーネル更新でまた PR kern/45361 で落ちるので問題の変更内容見てみたけど、PAキャッシュページカラーリングを承知の上で巨大PAキャッシュで問題になるのは分かってるのにちゃんと直すのめんどいからあえて無視してVIPT対応つっこんだ、という気がするのは偏見入り過ぎか
2011-10-18 20:50:13・uvmexp.ncolorsと別にuvm_[pv]a_ncolorsとマスクを用意 ・MDのncolors代入を上記に置き換え ・PAカラーリングではPAのを、COLORMATCHはVAのを使う ・emergvaのカラーはMDで最大値定義して使う ・recolorはPAのみ可
2011-10-18 21:01:06……でいいような気はするがMD部がめんどい。uvm_page_recolor()で即リターン、という投げやりworkaroundでいいんじゃないの、と思ったり
2011-10-18 21:02:15まあ、現状でもやたら効率悪いだけでいきなり再起動かかるのはほかにもうっかりバグが入ってるという気もするけど。いつものうっかり具合いだとするとさらに調べるのめんどい
2011-10-18 21:05:33しかしこんなあからさまにアレな内容を1か月以上放置なのはどうなんだろ。テキトーテストで問題なさそうだったら勝手にworkaround入れていいのか?
2011-10-18 21:14:53メモリ4GBのNetBSD/i386がメモリ使い果たして落ちないか確認してる横で メモリ16MBに増やしたNetBSD/luna68kでX超快適じゃんと言いながら動作テスト
2011-10-18 22:11:54L2キャッシュ1MBなのに 16 page colors って少ないなと思ったら Athlon II X2 の L2って 16-way なのか。その数でも変ってことは根本的にどこか誤ってるのかしらん
2011-10-19 00:48:24手元ソースの差分整理してたらmipsでこんなの出てきたけど誰も困ってないみたいだしほっといていいですよね http://t.co/8nEXy9wp
2011-10-19 01:13:12UVMテキトーパッチ改訂版はqemuビルド耐久を一応生き延びたみたいだけど、もう少し前向きな修正になるよう直してみるか……
2011-10-19 19:25:14uvm_map_findspace(9) に対して UVM_FLAG_COLORMATCH を指定したときとしないときとで引数 align の意味と中身が変わるという確信犯的手抜き実装のために 呼び出し元に対するチェックが果てしなくめんどくさい件
2011-10-19 19:29:33uvm_pagealloc(9) に UVM_FLAG_COLORMATCH を指定したときの off の意味は変わらない
2011-10-19 19:39:08uvm_km_alloc(9) に UVM_FLAG_COLORMATCH を指定したときは……VA確保で uvm_map(9) を、PA確保で uvm_pagealloc_strat(9) を呼ぶので、align の意味は変わるが offset の意味は変わらない。わかるかよ!
2011-10-19 19:44:24