Linux カーネルのメモリ管理サブシステムの５つの特徴
メモリ割り当て処理が先に進むことを保証しない 問題が発生する可能性があっても現実に起こるまでは対処しない 故意／悪意あるいはストレステストにより発生する問題には対処しない 自力で真犯人を逮捕できない一般人は相手にしない 他のカーネル開発者の関心を惹かない問題は解決されない 「え～っ！？」って思われましたでしょうか？でも、そういう世界なんだということが解ってきました。 Linux 4.9 で追加されてしまった warn_alloc() によるハングアップを「故意／悪意あるいはストレステストでなくても現実に起こる問題」として削除するのに丸１年かかりました。いやはや、疲れます。 「 Linux システムがハングアップしたらメモリ管理を疑え！？」という諺は、まだ有効です。意図的なストレスを掛けることで発生する問題は全力で無視されてしまうため、実際のシステムで使われている負荷を掛けることで発生するこ
Linux 4.9 が封印解除されたけれども・・・
今年はずっと「 Linux カーネルのメモリ管理機構の闇」と戦い続けてきました。 Linux カーネルのメモリ管理機構は「他の誰かが自分のために進捗を出してくれているから自分は余計なことを考えなくていい」という楽観論で動いています。そして、全員が同じ考えで動いたとき、誰も進捗を出せなくなり、システムは静かにハングアップしてしまいます。なんだか、責任の所在が不明な、某市場移転問題みたいですねぇ。 Linux 4.6 で OOM reaper が導入され、 Linux 4.9 では「 OOM killer が発動できる限りは OOM livelock 状態に陥らないことを証明できる」ようになる・・・ことを目指していました。しかし、誰も進捗を出せなくなったことを知らせてくれる仕組みとして、ストールしている間は１０秒毎に警告を出力するという楽観的な修正が取り込まれたことにより、 Linux 4.8
208.5 日問題の逆襲
昨年の始め頃、 208.5 日以上連続稼働すると動作が停止したり kernel panic が発生したりする可能性があるという TSC 絡みの不具合が話題になりました。 Linux カーネルの sched_clock() が 208.5 日の連続稼働でオーバーフローする現象について https://access.redhat.com/site/solutions/121233 Does Red Hat Enterprise Linux 6 or 5 have a reboot problem which is caused by sched_clock() overflow around 208.5 days? https://access.redhat.com/site/solutions/68466 しかし、上記の不具合を修正したカーネルには落とし穴があったようです。（誰も話題にしない
CaitSith という名前の由来について
LinuxCon North America 2012 で CaitSith の発表をすることになったので、ドキュメントの整備と動作テストが終わってから書こうと思っていた記事を投入します。 今までのアクセス制限モジュールはプロセスの視点からルールを書くため、特定のプロセスの動作を制限するルールを書くことは簡単でした。しかし、特定の資源へのアクセスを制限するには全てのプロセスの動作を制限しなくてはならないため面倒でした。資源の視点からルールを書くことができれば、そんな必要も無くなります。 CaitSith はプロセス視点でも資源視点でもお好きなようにルールを書けるので、「でっかい自分ルール」を実現できます。 さらに、 CaitSith ではホワイトリスト方式だけでなくブラックリスト方式でルールを書くこともできるようになっており、デフォルトでは許可も拒否もしない「あらあらうふふ」状態な動作をし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
tail -f が機能しない時にチェックすること
メモ： EOL した CentOS 4 用の yum 設定
configure スクリプトの -static オプションチェックについて
