革命の日々！ RHELのO_SYNCって面白い事になってるんだなあという話
昔、kernel watch で真のO_SYNCサポートについての記事（※下記参照）を書いたことがあるんだけど、RHELではちょっと事情が違うことがわかった。 ※ http://www.atmarkit.co.jp/flinux/rensai/watch2009/watch12b.html 時系列でいうと、まずkernel 2.6.33でO_SYNCサポートが入り（上記記事）、glibc 2.12 でそれに対応するためのヘッダファイル修正が入ったんだけど、RHEL6は kernel 2.6.32 + glibc 2.12 なんだな。 だからRHEL6でコンパイルしたアプリをRHEL6で実行するケース → O_SYNCはの実体は (__O_SYNC|O_DSYNC) なんだけど、カーネルのほうに、_O_SYNCの定義がないので、その部分は無視されて、O_DSYNCとして動作 RHEL6でコン
革命の日々！ おまえら rpmdev-setuptree を使えという話
いままで、rpmbuildするときに mkdir -p ~/rpmbuild/{BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS} して、 echo '%_topdir %(echo $HOME)/rpmbuild' > ~/.rpmmacros とかやってたんだけど、それはもう古いらしい。 % yum install rpmdevtools % rpmdev-setuptree すると、上記の両方をやってくれるのに加えて .rpmmacrosに並列処理設定を追加してくれる。 こんな感じ %_topdir %(echo $HOME)/rpmbuild %_smp_mflags %( \ [ -z "$RPM_BUILD_NCPUS" ] \\\ && RPM_BUILD_NCPUS="`/usr/bin/nproc 2>/dev/null || \\\ /u
革命の日々！ 2.6.34のused once ページに対する改善をcopybenchで検証してみた
従来のLinuxはread(2)やwrite(2)によるメモリアクセスは二回タッチでactiveリストへ移動だったのに、 mmapによるタッチは(pteのaccess bitが1bitしかない関係で）１回タッチでactiveリストになっていた。 そのため、現代的なマシンではmmapを使ってコピーすると逆に遅いという自体が発生していた。 以下のURL参照 http://d.hatena.ne.jp/kzk/20060513 んで、１年ぐらい前にmadviseしたときだけ、page activationを控えめにするパッチが入っていたのだが 今回2.6.34において、madviseなしでもused onceページはactiveリストに移動しないように論理が変更された。 と、定性的に説明するのも芸がないので、ベンチをとってみた。 測定ソフト --------------------------
革命の日々！ で、結局overommit_memoryのオススメ設定値はいくつなのさ？
あんまりエントリにするほどの分量はないんだけど、現時点でのオイラのオススメ値を貼っとく overcommit_memory=2 overcommit_ratio=0 swapパーティションのサイズ： 物理メモリ量ｘ８０％ overcommit_ratio=0 にすることで、全プロセスの仮想メモリ量がスワップサイズを超えなくなるので、カーネルによほど負荷をかけないかぎりスワップしなくなる。 んで、スワップを０にしたときと違って、カーネルに負荷をかけるようなスゲー使いかたをしたときでもスワップが発生するだけでOOM-killerは発生しない。 欠点は、ほぼ使わないと想定しているスワップに結構なディスク量をとられることだけである。 あ、あと、８０％というのはかなり適当に決めた値なのでシステムによっては９０％とかでもいけると思う。 注意１： この設定は組み込みでは全然使えません。なぜならサーバー系
革命の日々！ Gentooすげーー
http://www.nikkeibp.co.jp/it/article/NEWS/20091007/338507/ Gentoo Linux 10.0 Live DVDでは、主に各アプリケーションのバージョンアップが行われている。例えば、カーネル 3.6.30、glibc 2.9、gcc 4.3.2が採用されている。デスクトップ環境では、KDE 4.3.1（写真1）、GNOME 2.26.3、Xfce 4.6.1などが選択できる。さらに、OpenOffice.org 3.1.1、Firefox 3.5.3、GIMP 2.6.4、MPlayer 1.0 rc4などが利用可能だ。 いや、すごいのは日経BPか？ とにかく奴らは未来を生きているよ
革命の日々！ muninのプラグインを書いてみた
最近、kosakiという人が「オレはLKMLでもっとも頻繁にOOMバグの解析を行っているデベロッパの一人である。オレが言うんだから間違いない。現在のOOMの表示と/proc/meminfoはフィールドが足りない」と真偽が定かではない主張をして、フィールドを大量に増やすパッチを、ねじ込んだ。 ちなみに、現在の /proc/meminfoはこんな感じ $ cat /proc/meminfo MemTotal: 6037184 kB MemFree: 1229820 kB Buffers: 252336 kB Cached: 3673464 kB SwapCached: 0 kB Active: 1463432 kB Inactive: 2772100 kB Active(anon): 315332 kB Inactive(anon): 16 kB Active(file): 1148100 k
革命の日々！ FSベンチマーク対決
http://www.phoronix.com/scan.php?page=article&item=ext4_btrfs_nilfs2&num=1 たぶん、デフォルトパラメタで勝負しているので、ext3はwritebackモードだと思う。 要約 ・SQLiteテストはext3が20秒で終わるところが、ext4では870秒、btrfsに至っては1472秒もかかった ・PostgreSQLのpgbenchのbtrfs, XFSは完走できなかった ・IOZone Write: ext3:107MB/s, ext4:131MB/s, Btrfs:89MB/s Read: ext3:202MB/s, ext4:219MB/s, Btrfs:93MB/s Btrfs遅いな～ ・Dbenchはext3:100MB/s, ext4:32MB/s, Btrfs:46MB/s やはり、ordered-mod
革命の日々！ [linux-btrfs] btrfs vs ext4 benchmark
IBMのサーバでbtrfsとext4のベンチとったらbtrfsはクソ遅かったぜ。という話。 Hi, here are some tests on an IBM server with btrfs vs. ext4. Kernel: 2.6.29.1 Benchmark software: compilerbench with options -i 10 -r 30 CPU: Intel Xeon Quadcore E5310 Chipset: Intel 5000 Memory: 4 GB FB-DIMM DDR2-667 HDDs: 2x WD6400AAKS @ Raid0 Storage Controller: IBM Serveraid 8k btrfs Result: intial create total runs 10 avg 50.89 MB/s (user 0.85s s
革命の日々！ ext3のデフォルトモードがwritebackに変わっちゃった件について
ext3のlatency問題に嫌気がさした、linus。 とうとうext3のデフォルトモードをorderedからwritebackに変えちゃった。サインが彼一人なのを見ても分かるように、誰にも相談せずに・・・ commit bbae8bcc49bc4d002221dab52c79a50a82e7cd1f Author: Linus Torvalds Date: Mon Apr 6 17:16:47 2009 -0700 ext3: make default data ordering mode configurable This makes the defautl ext3 data ordering mode (when no explicit ordering is set) configurable, so as to allow people to default to 'data
革命の日々！ Aligning filesystems to an SSD’s erase block size
という記事をTed TsoがBlogに書いている http://tytso.livejournal.com/60368.html 要約すると、 ・今のLinuxはセクタサイズが512byteで決めうってあるけど、IntelのSSDは128Kだよ。HDDも将来は4kに変わるよ。 ・今のLinuxのstorage subsystemはalignmentを考えてないよ。手動で調整する必要があるよ。やり方も載せるよ ・alignmentがあってないと、書き込みが、read-modify-writeになるから遅いよ。SSDだけじゃなくRaid5でもalignmentは意識しないと遅くなるのでGenericな問題だよ ・Vistaはもう4k align対応は終わってるよ（128K align対応はまだだけど） ・将来的には全自動になるべきだよ。（fdisk時のファイルシステムのアライメントとか、mkf
革命の日々！ 連載中止するかも
ジェットコースター的展開 某連載の編集者様から、不況だから原稿料下げますというメールが来た。むーん、そんなに不人気だったのか。しかも割合がでかい。 元々、執筆にはかなり時間を取られていたので時給閑散では最低賃金を大幅に下回っており、時給閑散では被害がすくないのだが、これって自己欺瞞だよな。とかとか LKMLを全部読むというのはヨガの賢者も真っ青の苦行だったので、やめるなら今がチャンスでもある。 現在、関係者と鋭意協議中。
革命の日々！ ext4がいつの間にか結構高速化していた件について
あれ、ほとんどの項目でext2に勝ってるじゃん。 On Wed, Jan 07, 2009 at 11:29:11AM -0800, Curt Wohlgemuth wrote: > > I ran both iozone and compilebench on the following filesystems, using a > 2.6.26-based kernel, with most ext4 patches applied. This is on a x86 based > 4-core system, with a separate disk for these runs. Curt, thanks for doing these test runs. One interesting thing to note is that even though ext3 was ru
革命の日々！ squashfsがマージされました
squashfsというのはcramfsと同じくread onlyだけど圧縮をサポートするファイルシステムで組み込みのルートファイルシステムによく使われています。 cramfsは超大昔にLinusでお遊びで作ったファイルなので、 ・最大ファイルシステムサイズが小さい ・最近のモダンなフィーチャーに一切対応していない といった問題があったのでした。 ここで、Phillip Lougher による比較表どーん Squashfs Cramfs Max filesystem size: 2^64 256 MiB Max file size: ~ 2 TiB 16 MiB Max files: unlimited unlimited Max directories: unlimited unlimited Max entries per directory: unlimited unlimited M
革命の日々！ relatimeがどこで実装されているのか調べてみた
ITProのLinuxチューニングの記事がひどい事になっている件について http://mkosaki.blog46.fc2.com/blog-entry-535.html という数本前の記事について、id:shiumachiさんが追試してくれました。 つ http://d.hatena.ne.jp/shiumachi/20080605 むむむ、すばらしいです。 特にrelatimeのあたりが秀逸です。relatimeの性能測定って他にあんまりないのではないかしら。 複数の方からご指摘いただいておりますが、noatimeはあの記事のなかで数少ない、現在でも意味のあるオプションです。 せっかくなので、お礼がてら、relatimeについてちょいと追記してみます。 まず、atimeまわりのオプションの意味から デフォルト： 常にatimeを更新する noatime： 常にatimeを更
革命の日々！ なんで、pthread_once()なんて存在するの？
http://d.hatena.ne.jp/amachang/20080612/1213244820 お気に入りなサイトのIT戦記より // ここを volatile にする // （この変数の値はアトミック（つまり、レジスタにだけあってメモリにないということがない変数に）になる） volatile char* p = NULL; pthread_mutex_t m; void* f(void* _p) { // ロックかからない if (p == NULL) { pthread_mutex_lock(&m); // ここからはクリティカルセクション // 一個目の初期化時にここでブロックしたスレッドのために // もう一回 NULL チェック if (p == NULL) { // ここではまだ p に代入しない // 代入したら別スレッドで初期化されていない p が返ってしまう cha
革命の日々！ シーケンスロック その５ volatileがダメな理由
どもども。またまた間隔があいてしまいましたがシーケンスロックな話しの続きです。 前回の記事で坩堝さんから面白い指摘をうけたので今回は予定を変更してvolatileの話をしたいと思います。 retをvolatileにするだけではうまくいかないんですよね？ どういう風になるんだろ． なるほど、たしかに世のＣ言語の参考書を見るとvolatileはある種の最適化を妨げる効果を持つと されています。 これだけ見ると、volatileとつけるだけすべての最適化が無効になってうまく動きそうですね。 しかし、その理屈は微妙におかしいのである 多くの人が「ある種の」という言葉を拡大解釈しているがvolatileは本来スレッド同期に使えるようなシロモノではないのである。 つづきは、続きを読むからご覧ください。 あと、お願い。 今回の話は前提知識がいろいろとあるので、末尾のご参考にあげたURLを読んでから 読ん
革命の日々！ linuxのmlockが凶悪な件について
諸卿もご存知の通り、Linuxのメモリアロケーションはmalloc(), mmap()した段階ではメモリ割付をせず、最初にメモリにアクセスしたときに行うという俗に「first touch」と呼ばれるアロケーションポリシーを採用している。 さて、んでは、このmmap()したけどまだ実際にはメモリ割付されているないアドレスにたいしてmlock()したらどうなるか。 というと、この時点でメモリ割付が走る。 走るのはいいんだが、これがまたベラボーに遅い。 別にLinuxカーネルのアルゴリズムが悪いわけではなくて、メモリ割付をする＝そのページを０クリアするという事なので、DRAMのアクセス速度が超えられない壁となって立ちはだかるわけだ。 じゃあ、どのくらい時間がかかるか計算してみよう。 まず、DRAMをDDR2 PC5300と仮定しよう。イマドキ、こんなもんよね。 これでアクセス速度理論値 5300
革命の日々！ カーネル読書会で講演してきました
７月にLMSで発表したglibc mallocの解説を、ブラッシュアップしてYLUG・カーネル読書会でも発表してきた。 本人の知らない間にビデオ撮影をして、YouTubeにアップするとかいう話になっていたので、「ちょ・・業務用です・・・か？？」とでも言わんばかり、かなり本格的ビデオカメラが会場に設置されていた。 もうダメである。 緊張しまくり、用意しておいた小ネタギャグは一切言えなかった。 熱いトークを期待したいた皆さん（いるのか？）ごめんなさい。 てゆーか、ネクタイに指す、アナウンサー向けっぽげなマイクが用意されているあたりがYLUGスゴス。と思った。 まあ、それはさて置き、当日の感想としてはhyoshiokさんのBlogあたりの感想がよくまとまっていていい感じなのではないかと思う。 結論： みんなRubyが好きなんだよ。 kernel hackerもLL hackerも交流しようよ と
革命の日々！ MySQLがlinuxで遅いのはglibc mallocのせい？
http://blog.miraclelinux.com/yume/2007/02/mysqllinux_472a.html MySQLのマルチコアスケーラビリティとLinux スラッシュドットの情報。FreeBSDとLinuxでsysbench(MySQLを利用している)の結果が出ている。結論から言うと8コアのAMD64のマシンでスレッド数を上げていくと8スレッドまではLinuxでの性能が良かったが、それ以上になるとがたっと性能が劣化して、FreeBSDのSMPngの実装が勝つ。 下記を参照してほしい。 http://jeffr-tech.livejournal.com/6268.html あれちゃうか。 たぶん、MySQLがマルチスレッド環境下でmallocとfreeが毎回異なるスレッドになっているんちゃうか。 mallocかfreeのどちらかがマネージャースレッドでまとめてやっている
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
革命の日々！ jemallocの資料