OSS開発勉強会-02

559 views

Published on

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
559
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
4
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

OSS開発勉強会-02

  1. 1. OSS開発勉強会-02 Mail Reading: SELinux scalability improvement using RCU NEC OSS推進センター 海外 浩平 <kaigai@ak.jp.nec.com>
  2. 2. SELinux scalability improvement using RCU プロジェクト期間 2004年8月~9月 やった事 SELinuxがアクセス制御の意思決定を行なう関数は、 Spinlock (排他ロック)で保護されていた SMP環境でも1CPUが同時実行の限界、性能のボトルネック RCUを使ってロックを置き換え、リニアスケールを実現。 Linux kernel v2.6.11 で標準化 主な登場人物 Stephen Smalley (NSA) James Morris (Red Hat) Paul E.McKenney (IBM)
  3. 3. SELinuxの内部構造 (v2.6.9) System Call 実装部 SELinuxアクセス制御 (avc_has_perms()関数) spin_lock_irqsave() avc_lookup_cache() spin_unlock_irqsave() 待ち 待ち 待ち 許可 or 禁止 CPU1 CPU2 CPU3 CPU4 security policy 参照 load_policy()関数 書換え
  4. 4. RCU (Read Copy Update) 「Readアクセス >> Writeアクセス」なデータ構造で有効 E.g) SELinuxのセキュリティポリシー ポインタの更新がアトミックに行なえる事を利用した技術 Write時のコストは Lock を利用した場合よりも高いものの、 Read時のコストは0に近い 要素1 要素2 要素3 要素4 コールバック関数 kfree() COPY 要素3要素3'
  5. 5. MLでの議論 Sat, 7 Aug 2004 22:57:08 -0400 (EDT) James Morris <jmorris@redhat.com> wrote: > > The biggest problem is the global lock: > > > > avc_has_perm_noaudit: > > spin_lock_irqsave(&avc_lock, flags); > > > > Any chance we can get rid of it? Maybe with RCU? > > Yes, known problem. I plan on trying RCU soon, Rik was looking at a > seqlock approach. I'm interested in the scalability of SELinux, and tried with rwlock and RCU approaches. I simply replaced spinlock_irq_save() by (read|write)_lock_irqsave() first, but performance improvement was observed in the hackbench : : : On Mon, 16 Aug 2004, Kaigai Kohei wrote: > Is removing direct reference to AVC-Entry approach acceptable? > > I'll try to consider this issue further. Sure, if you can make it work without problems. - James -- James Morris <jmorris@redhat.com>
  6. 6. MLでの議論 (1/2) The attached patches against to 2.6.8.1 kernel improve the performance and the scalability of SELinux by RCU-approach. The evaluation results are as follows: <Environment> CPU: Itanium2(1GHz) x 4/8/16/32 Memory: enough (no swap) OS: 2.6.8.1 (SELinux disabled by 'selinux=0' boot option) 2.6.8.1 (SELinux enabled) 2.6.8.1 + rwlock patch by KaiGai 2.6.8.1 + RCU patch by KaiGai The test program iterates write() to files on tmpfs 500,000 times in parallel. It is attached as 'rcutest.c'. We observed performance improvement and perfect scalability. --- 4CPU --- --- 8CPU --- --- 16CPU --- --- 32CPU --- 2.6.8.1(disable) 8.0158[s] 8.0183[s] 8.0146[s] 8.0037[s] (2.08/ 6.07) (1.86/6.31) (0.78/ 7.33) (2.03/5.94) 2.6.8.1(enable) 78.0957[s] 319.0451[s] 1322.0313[s] too long (2.47/76.48)(2.47/316.96) (2.43/1319.8) (---/---) 2.6.8.1.rwlock 20.0100[s] 49.0390[s] 90.0200[s] 177.0533[s] (2.57/17.52) (2.45/46.93) (2.37/87.78) (2.41/175.1) 2.6.8.1.rcu 11.0464[s] 11.0205[s] 11.0372[s] 11.0496[s] (2.64/8.82) (2.21/8.98) (2.67/ 8.68) (2.51/8.95)
  7. 7. MLでの議論 (2/2) James Morrisから 1or2CPU環境での性能が気になる 計測してみた → Single-Thread テストも悪くない あと atomic_inc_return() って i386 で実装されてなくね? これは、後に各アーキテクチャに移植する事に Paul E.McKenny登場 RCUアルゴリズムの開発者 当時、RCUはLinux kernelで限定的な使われ方がされていた そのためか、進んでレビューを引き受けてくれる。 Stephen Smalley 実行時に kmalloc() して大丈夫なん? Lockを獲得するパスがあるけど、それでいいの?
  8. 8. 最初のコメントを振り返って 大失敗パッチ kmalloc()の失敗を考慮するくらいなら、リストの各要素を二重 に持って、更新時は裏面に書き込んで後で切り替えれば…? 2スレッド以上が同時にリストを更新しようとした時はどうするんだ? 撃沈 元々、更新の頻度は低いのだから、write時はロックでも良い 要素1 要素1’ 要素2 要素2’ 要素3 要素3’ 要素4 要素4’
  9. 9. Take-4 パッチ Write時だけはロックを獲得するように修正 kmalloc()失敗時は、cacheを使わないパスにfallback 要素1 要素2 要素3 : : : : Lock Lock Lock : : : : read時 RCUを使いLockレスで参照可 write時 Hash-bucket毎のLockを取る Spinlock配列 Hash表 lru_hint
  10. 10. atomic_inc_return()パッチ atomic operations メモリ上で『フェッチ→演算→ストア』の一連の流れが アトミックに行われる事を保障する。 Hash表からItemを回収する際に、スロットの選択のために lru_hintをアトミックに操作したかった。 実装はアーキテクチャ依存 当時、ia64では実装済みも、i386やarmでは未提供だった パッチ i386, x86_64, arm, arm26, sparc64 向けに投稿 これで、全アーキテクチャで atomic_(inc|dec)_return() が 利用可能となった。
  11. 11. Linux-2.6.11で統合
  12. 12. ポイント その道の専門家を上手く使う Paul E.McKenny (IBM) はRCUの開発者 当時、イマイチ理解が不十分であったポイントに対しても、 的確なコメントでヘルプ 各アーキテクチャのメンテナー ARMやSPARC64のハードなど持っていないが、メンテナーに レビューを依頼。実機で一度も動かした事のないコードをマージ。 コミュニティの重鎮を味方に引き入れる Stephen SmalleyやJames MorrisはSELinuxのメンテナー 早期にコードを公開し、フィードバックを反映させる。 ☓ バッドノウハウ IBMのLTCのメンバが取り組んでいた、SeqLockを用いるアプローチは、 コードの公開が遅れ、結局、Linux kernelへの統合を断念する事に

×