メモリ削減パッチ再提出

また提出しなおし。
ひたすらベンチマークとった。
http://marc.info/?l=selinux&m=118767082011094&w=2
さらにハッシュスロットへらして、300ｋ超のメモリを節約した。

ハッシュ関数変えたけど、ハッシュテーブルの利用状況は良くとも、
ハッシュ関数が遅くなるほうが上回り、
全体として遅くなるので、変えないほうがいいという結論。

ちなみに、測定の中で、
ポリシーのサイズが小さくなると、
security_compute_avが遅くなっているように見える現象を発見した。
KaiGaiさんに聞いたら、アトリビュートが怪しいのではとのこと。
security_compute_avから呼ばれる関数に以下のような処理がある。

331         sattr = &policydb.type_attr_map[scontext->type - 1];
332         tattr = &policydb.type_attr_map[tcontext->type - 1];
333         ebitmap_for_each_bit(sattr, snode, i) {
334                 if (!ebitmap_node_get_bit(snode, i))
335                         continue;
336                 ebitmap_for_each_bit(tattr, tnode, j) {
337                         if (!ebitmap_node_get_bit(tnode, j))
338                                 continue;
339                         avkey.source_type = i + 1;
340                         avkey.target_type = j + 1;
341                         for (node = avtab_search_node(&policydb.te_avtab, &avkey);
　　　＜略＞
350                         }

つまり、ドメイン側とタイプ側に付与されたアトリビュート全ての組合せに対して、
avtab_search_nodeを呼んでいる。
調べてみると、
strictポリシでは、例えばkernel_tには8個アトリビュートが付与されているのに対し、
targetedでは、kernel_tに24個も。
遅くなるわけだ。

お、早速返事が返ってきた。
概ねよさそうだ。あとはコーディングスタイルの問題っぽい。
そういえば、カーネルコーディングのお作法はよく知らないなぁ。勉強しなきゃ（汗