-
- いいね！0
KOSAKI Motohiro
@kosaki55tea
@nullnilaki @cvsync あとさあ、ユーザ空間で隣り合ったページがキャッシュインデックス一致してると云々ってのは行列計算みたいなアクセスパターン想定してるっぽいけど、そういうのはイマドキはauto prefetchがあるからキャッシュミスがノーペナになる可能性あるし
2015-08-17 02:10:51
Lucky owner/capturer
@nullnilaki
@kosaki55tea @cvsync 速くなる、遅くなるはケースバイケース かつ SMPが当たり前でauto prefetch持つような最近のCPU向けの技術では ないということですか...
2015-08-17 02:16:21
MAEKAWA Masahide
@cvsync
@kosaki55tea いやいや... 私カーネルとか CPU とかキャッシュとかそういうの全然分からないマンなので勉強になります。
2015-08-17 02:16:28
Lucky owner/capturer
@nullnilaki
@cvsync @kosaki55tea ゴメンネなんて絶対無いです 不勉強なので、すっごい勉強になりました 今日指摘していただいた事は、消化して、いつかぜったい話題がかみ合うように なってみせます
2015-08-17 02:19:12
Izumi Tsutsui
@tsutsuii
PIPTの page coloring で効果が見れるのは昔の direct map の巨大な L2 での話で、今時の way数が 4とか8とかあって color が少ない場合は効果があるかは不透明。さらに今は ASLRとかもあるので何をどう測るのか評価が難しいと思われる。
2015-08-17 02:21:27
Izumi Tsutsui
@tsutsuii
NetBSDの page coloring の実装は新たな物理ページを取ってくるときに color分の pool を用意して round robin しているだけなのでオーバーヘッドは少ないと思われるけれど、管理領域が L1より大きくなったらダメじゃないの? とかいう心配はある
2015-08-17 02:22:32
Izumi Tsutsui
@tsutsuii
今時のプロセッサ構成であればそんな太古の定性的な話よりも物理プロセッサグルーピング（用語忘れた）とか実用的かつハード設計と連携しないとうまくいかないような領域を潰しが利くようにうまく(?)実装する、というほうに注力したほうが良いとは思う。
2015-08-17 02:23:51
Lucky owner/capturer
@nullnilaki
@tsutsuii つついさん、まだ起きとったんですか！ たしかにmsaitohさんも最近のCPUはwayだしねぇという話をされてました。
2015-08-17 02:24:06
Izumi Tsutsui
@tsutsuii
その辺りになってくると論文を読んで一人でシコシコ実装するというレベルではなくなってきて、理屈を元にきっちり設計できる人、設計通りの機能を実装できる人、実際のハードとアプリで正確な評価のできる人、それぞれが必要で、それなりの企業でフルタイムでやってる人がいないと不可能という感じ
2015-08-17 02:26:02
Lucky owner/capturer
@nullnilaki
@tsutsuii これはですね、あったよーな、なかったよーな感じです。 ベンチマークを連続して2回連続で走らせた時、2回目がチョビッと速くなりました。
2015-08-17 02:29:16
Izumi Tsutsui
@tsutsuii
PIPTの page coloring は「やると効果があるかも」だけれど、VIPTの page coloring は「やらないと動かない（あるいは cache flush だらけになって全然性能が出ない）」であるという問題
2015-08-17 02:37:39
Izumi Tsutsui
@tsutsuii
が、DMA-cache coherency の問題と同じで「それを人類がOS上で設計実装するには難しすぎた」という感じで、結局全部CPUでがんばっている（way数を増やして index がページサイズを超えないようにしている）という気がする
2015-08-17 02:38:46
成田 良一
@ahren6
#kernelvm 会場説明の後に撮った RICHO THETA による360度画像です。 theta360.com/s/k6MEjlKxPCBX… …
2015-08-17 02:42:35
Izumi Tsutsui
@tsutsuii
過去に pmap_page_idle_zero という実装があって、「VMのうち物理ページのゼロ初期化が重いからCPUが暇なときに空いてるページを zero fill しよう」という発想で実装されていた。単純で効果があるように見えて、実際には性能が出ないという難しい結果に
2015-08-17 02:44:32
Izumi Tsutsui
@tsutsuii
・CPUがI/O完了待ちだった場合は何もせず引き続きキャッシュにデータが残っていたほうが速い ・CPUがヒマな隙にバスマスタI/Oが全力でDMAしている場合もあってそれをCPUが邪魔することになる 等々、いろんなケースがあって結局無効にされていたよーな気がする
2015-08-17 02:48:01
Izumi Tsutsui
@tsutsuii
15年くらい前のカーネルプロファイルだと確かに pmap_zero_page() が3割くらいを占めていたという結果を見たことがあるけれど、正直いまどきのCPUとOS実装だとどこがネックなのかさっぱり理解していない素人(ヽ´ω`)
2015-08-17 02:49:10
Izumi Tsutsui
@tsutsuii
結局、キャッシュやI/Oの部分はOS側からは観測できないので正確なシミュレーターを用意してその上で測る必要があるけれど、現状キャッシュまで正確にエミュレートするシミュレータなんてCPUメーカーしか持ってないんじゃないかという気はする（そんなのエミュレートしても遅くなるだけなので）
2015-08-17 02:54:13
Izumi Tsutsui
@tsutsuii
@nullnilaki 確認したことがないのでわかりませんが 仮説1) ページサイズを大きくしている 仮説2) そういうCPUはまともにサポートしてない 仮説3) colorが違うVAにマップされたらキャッシュ無効にする くらいですかねえ。IRIXの実装を見てみたいところです
2015-08-17 02:56:29
Izumi Tsutsui
@tsutsuii
NetBSD/sh3 の SH4の実装だと「同じ物理ページが異なるcolorのVAにマップされたら先にマップされていた方をアンマップする」という実装だったけれど、shlibだったかで「同時にアクセスできないと進まない」という問題が発生して uncached にするようにしたような
2015-08-17 02:59:56
Izumi Tsutsui
@tsutsuii
そもそも ユーザーランド側でそういうマッピングが発生しないようにABIをなんとかしろよ という話でもあるような気がするけれど、そもそも本来ソフトからは不可視であるべきなキャッシュ実装に対してABIまで関与が必要というのも思想としてどうよ という話もある
2015-08-17 03:01:32