革命の日々！ linuxのmlockが凶悪な件について
諸卿もご存知の通り、Linuxのメモリアロケーションはmalloc(), mmap()した段階ではメモリ割付をせず、最初にメモリにアクセスしたときに行うという俗に「first touch」と呼ばれるアロケーションポリシーを採用している。 さて、んでは、このmmap()したけどまだ実際にはメモリ割付されているないアドレスにたいしてmlock()したらどうなるか。 というと、この時点でメモリ割付が走る。 走るのはいいんだが、これがまたベラボーに遅い。 別にLinuxカーネルのアルゴリズムが悪いわけではなくて、メモリ割付をする＝そのページを０クリアするという事なので、DRAMのアクセス速度が超えられない壁となって立ちはだかるわけだ。 じゃあ、どのくらい時間がかかるか計算してみよう。 まず、DRAMをDDR2 PC5300と仮定しよう。イマドキ、こんなもんよね。 これでアクセス速度理論値 5300
FirefoxのEUCの独自拡張のセンスが最低な件について
前回の記事について、説明が不足していたようで、404 Blog Not Found様からmultipart/form-data を忘れている とお叱りを頂いてしまいました。 えっと、誤解です。 multipart/form-dataを使っても状況はまったく変わらないことが分かったので説明を省略しただけです。 誤解をとくために前回の調査結果を簡単にまとめさせてください。 ・Webの世界でEUCといったらCP51932がデファクトスタンダードである ・これは本来のEUCから補助漢字をなくして、かわりにWindows機種依存文字を 追加したものである。 ・しかし、FirefoxだけはCP51932+補助漢字という独自拡張EUCを採用している。 ・これはURL Encoding の％エスケープを解いたあとのデータが補助漢字に ついて生EUCとするか、数値文字参照とするか、という違いとして現れてくる
革命の日々！ 誰も読まないOSのソース・コード
日経BPのサイトに、誰も読まないOSのソース・コードという記事がアップされている。 わりと衝撃的な見出しから始まるのでさくっと引用 まず，結論から言おう。 「エンジニアがOSのソース・コードを読めるようになると，活躍の場が一気に広がる」。そして，「コツさえ分かれば，OSのソース・コードはびっくりするほど簡単に読める」。 赤松氏が「ソースを読んでいる人がほとんどいない」と感じる理由はもう1つある。それは，誰もがよく使うソフトでさえバグが大量にある，ということだ。少しでもソースをのぞけば，誰にでもすぐに見つけられるほど簡単なバグなのに，ネットにも情報が上がらず放置されているという。例えば，赤松氏が見つけたバグの具体例を一つだけお見せしよう。 まあ、寝言は寝てから言ってくれといった感じだが、カーネル読めるぐらいで生活は楽にならんっちゅーの。 だいたい、アンタprocfsとネットワークしか読んでな
革命の日々！ tmpfs は本当に容量が動的なのか
動的です。おわり ああ、石投げないで。 はてなの伊藤直也さんのblogでそういうエントリを見つけたので。 記事のネタが欲しかったんだよう。 で、伊藤さんが書いているremountしたらスワップ発生ってのを考えていたんだが、まったく思いつかんのよ。原因が。 カーネルソースもみなおしたけどremountってｆｓ管理構造体のmax_sizeメンバとかに再代入してるだけで、ぜんぜんメモリ確保してないし。 さらに言えば、tmpfsはファイルシステム上に100Mのファイルがあるときに50Mのサイズでリマウントしようとした場合、シュリンクの努力はなにもせずにエラーリターンするという特徴があるため、 サイズを減らす方向のremountが成功したのなら、サイズを増やしたぶんのファイルシステムスペースは使っていなかった可能性が高いのである。 うーむむ、現時点ではたまたま別の要因がうごいたんじゃない説がイチオシ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
