なんで、linux-mmに直接投げなかったかというと、marceloの提案(下に引用する)通りに
So something like the following sounds better:
- have your poll_wait_exclusive() patch in place
- pass a "status" parameter to mem_notify_userspace() and have it clear
mem_notify_status in case status is zero, so to stop sending POLLIN to processes.
- call mem_notify_userspace(0) from mm/vmscan.c when ZONE_NORMAL reclaim_mapped
is false (that seems a good indication that VM is out of trouble).
- test for mem_notify_status in mem_notify_poll(), but do not clear it.
- at mem_notify_userspace(), use wake_up_nr(number of mem_notify users/10) (10
meaning a small percentage of registered users).
実装すると、memory pressure状態を抜けたときに脱出通知がされず(そもそもshrink_active_listが呼ばれないので、んな所で判定するのが間違ってる)
一度でもmemory pressure状態になると二度とturn offされないからである。
どうでもいいが、パッチセットの説明にカーネルコアへの影響を最小限にした云々と書いた割りに、すでに
[1/5] おれ専用APIをselect.cに追加
[2/5] eventpollをおれの都合で書き換え
[3/5] wait.hにオレ専用APIを追加
[4/5] メモリ通知デバイスの追加 ←本当のパッチ
[5/5] vmscan.cをおれの都合で書き換え
という、どこが最小限やねんwwというパッチセットになっているのは秘密だだだ
ようやく分かった。
~/.quiltrcに以下の内容を書いて、おいら的には幸せ度がだいぶあがりました。
QUILT_DIFF_ARGS="-p ab --color=never"
QUILT_DIFF_OPTS="-up"
QUILT_REFRESH=ARGS="--difstat -p ab"
FC2ゆるすまじー
とりあえず自分的に納得できたのでよし
怒られたら、ダッシュで逃げよう
∧_∧
( ・ω・)=つ≡つ
(っ ≡つ=つ
/ ) ババババ
( / ̄∪
搭載メモリ16GBまではスケールしてるみたいだ。
あとはNUMA対応か。
やはり現代的CPUでTLBオフを提示するのはCPUメーカとしていかがなものかと
超よかったっす。しあわせ。
冒頭の第一声、世間の人がどう思っているかはともかくとして天文学者をやっている牧野です。よろしくお願いします
で聴衆のハートをわしづかみ。うますぎる
その後の飲み会も今後のCPUアーキテクチャーの話やらT2Kの話やらの濃ゆい話でもりあがる。
こういう濃ゆい話が出来る人と知り合いになれることは本当に素晴らしいことだとかマジメにオモタ
そういえば笹田さんがLinuxのaioは使いにくいという話をしていた気がするのだけれど一晩寝たら完全中身を忘れてしまった。
今度あったら恥を忍んでもう一回聞こう
よくみると、うちのはiowaitまみれや。これってディスクが遅いって事?
視点が新鮮なので、結構楽しめた。
でも調査不足が感じられるので、このネタで1年間講義とはできまい。とかおもた
まあ暇つぶしにはいい感じですよ。安いし。
あと死ね死ね団超カッコイイ!!
えらいつかれた
結局、
ターゲットユーザ(ターゲットアプリと言うべきか)
1.FATアプリケーション(例:ブラウザ、JVM、DB)
自分のキャッシュを捨てる
2.userland oom manager
システム管理者がメモリ足りないときの振る舞いをカスタマイズするためのデーモン
通知してほしいタイミング
1.スワップが始まる直前
2.謎(OOMが始まる直前だと普通通知受けてる間にカーネル内ではすでにOOMに突入しちゃうので手遅れになりがち)
何人起こすか?
1.Thundering herd problemsを避けるために1人づつ。
てか、全員が一斉にメモリ捨てたらfree量が増えすぎるだわさ
2.オレを起こさないときがあるなんて許さん
ステークホルダー
- Marcelo Tosatti
- Daniel Spång
- Rik van Riel
法改正で普通免許はなくなったとかで、中型免許をもらったのだが、中型があるってことは
小型もあるのか?
軽自動車専用とか(´・ω・`)
習慣で飲んでしまう。
とゆーわけで、布教いたす。
だれか、だまされたと思って飲んでみ。感想はコメント欄へドゾー

ベイリーズ・アイリッシュクリーム
●症状
IE7(Internet Explorer 7)でYahoo! JAPANなどの一部ページにおいて、IE7の文字サイズをDefaultの「中」から「大」などに変更。
その後、IEを閉じて再度開きなおしたり、一度他のページに飛んだ後で再表示すると文字サイズが「中」に戻ってしまう。
文字サイズの変更がちゃんと反映されているページもある。
●結論
IE7の不具合でした!
ただし、WindowsXP版のIE7では問題は発生しない模様。
以下、Microsoft社サポート技術情報ページの事例より引用(リンクは下記に貼ってます)
これ、おもしれーな
・UTF-8では問題が発生しない
・保護モードOFFでも問題は発生しない
というところを見ると以下のようなストーリーだと思う。
まず前提
ブラウザの内部実装においてページの内容をいじるには2つ流儀がある。
1つめはフィルター方式でHTTPレイヤから吸い取ったデータをHTMLパーサに渡す前に変換して渡しちゃうんだな。伝統的な文字コード変換はこのレイヤで行っている。
2つめは匿名ページ作成方式(名前は今てきとうに作った)、メモリ上に好き勝手なHTML等のデータを構築しておいて、そこにページ遷移するんだな。典型的にはページロード後にjavascriptでdocument.writeしちゃったときにこうやって匿名ページ構築&遷移してHTML書き換えに対応することがおおい(個人的には99%コーディングミスなのでいらない機能だと思っているが)
んで、たぶんIE7では
・内部コードがUTF-8
・保護モードONのときだけ文字コード変換がフィルター方式から匿名ページ作成方式にスイッチしてる
・文字サイズ記憶ロジックのURL比較論理において匿名ページ関連に抜けがある
ってあたりかな。と
いや、IEなんて知らないけど。
たぶんあれだね。
文字コードバイナリアン(なんだそれw)のはせがわ先生ご指摘の穴
http://openmya.hacker.jp/hasegawa/public/20061209/momiji.html
をふさぐために、急いで文字コード変換まわりをいじってテスト期間が足りなかったのではないかと推測。
こんだけブロードバンドが普及しちゃうともうほとんで意味ないんだけど、やっぱりブラウザセキュリティにおいて最大の急所はページ読み込み時のインクリメンタルレイアウトなのは間違いのないところで、DOM構造とか完全に無視してパケット来た順に4kバイトとかの単位でパースしていくんだから、そら境界条件とか穴もできる。
・・・と、この話は文字サイズの話に収まらないので、別記事にしよう。

対策は適切に! ランキング!
たまにしか回収しない種類なんかは、朝寝坊したりすると当分ごみが家に残ってしまうので憂鬱になってしまう。
んで、引越しの際に出た山のようなゴミにいいかげんイライラ来てたので、ゴミ収集センターに直接持ち込んで一気に処分してきた。
車に乗るかどうかあやしいぐらいのゴミが一気に処分できていい気分。
よく考えたら機器類は中古屋さんに持ち込めばちっとは金になったような気もするけどまあいいか
