January 2009

2.6.29 の目玉機能になってしまうでしょう。とほほ

ほとんどの人がbtrfsdevかレビュー指摘が反映されるまでペンディングする事を 指示 支持していたのに、なぜかそのままのコードがマージ。
おどろきすぎる。

Linusの発言が1個もなかったから、議論を読まずにうっかりマージしたんじゃないかと勘ぐってしまう。
このエントリーをはてなブックマークに追加

今回も知らなかったよ。なんで教えてくれないんだ?!
このエントリーをはてなブックマークに追加

あれ、ほとんどの項目で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 running with barriers disabled, and ext4
was running with barriers enabled, ext4 still showed consistently
better resuls. (Or was this on an LVM/dm setup where barriers were
getting disabled?)

I took the liberty of reformatting the results so I could look at them
more easily:

Iozone, 1 Thread
Average throughput ext2 ext3 ext4 ext4-nojournal
Type Mean Stddev Mean Stddev Mean Stddev Mean Stddev
initl_writers: 56.6 MB/s (0.2) 56.3 MB/s (0.2) 65.5 MB/s (0.1) 66.3 MB/s (0.2)
rewriters: 58.4 MB/s (0.2) 58.2 MB/s (0.1) 65.7 MB/s (0.2) 66.6 MB/s (0.1)
readers: 66.3 MB/s (0.2) 66.4 MB/s (0.1) 65.8 MB/s (0.2) 66.4 MB/s (0.0)
re-readers: 66.5 MB/s (0.0) 66.1 MB/s (0.2) 65.6 MB/s (0.3) 66.4 MB/s (0.0)
random_readers: 22.4 MB/s (0.1) 22.1 MB/s (0.1) 21.9 MB/s (0.0) 22.4 MB/s (0.1)
random_writers: 18.8 MB/s (0.0) 18.6 MB/s (0.1) 19.1 MB/s (0.1) 19.4 MB/s (0.2)

Iozone, 8 Threads
Average throughput ext2 ext3 ext4 ext4-nojournal
Type Mean Stddev Mean Stddev Mean Stddev Mean Stddev
initl_writers: 28.5 MB/s (0.0) 28.7 MB/s (0.1) 53.7 MB/s (0.2) 56.1 MB/s (0.1)
rewriters: 43.5 MB/s (0.1) 43.2 MB/s (0.2) 58.3 MB/s (0.1) 60.3 MB/s (0.2)
readers: 51.5 MB/s (0.1) 51.5 MB/s (0.0) 58.8 MB/s (0.1) 61.0 MB/s (0.0)
re-readers: 51.8 MB/s (0.2) 51.5 MB/s (0.0) 59.0 MB/s (0.1) 61.0 MB/s (0.0)
random_readers: 20.3 MB/s (0.0) 20.2 MB/s (0.0) 20.2 MB/s (0.0) 20.4 MB/s (0.1)
random_writers: 17.3 MB/s (0.0) 17.3 MB/s (0.0) 18.1 MB/s (0.0) 18.3 MB/s (0.1)

Compilebench
Average values ext2 ext3 ext4 ext4-nojournal
Type Mean Stddev Mean Stddev Mean Stddev Mean Stddev
init_create: 57.9 MB_s (1.9) 30.6 MB_s (2.2) 59.7 MB_s (0.4) 77.1 MB_s ( 0.2)
new_create: 13.0 MB_s (0.2) 13.5 MB_s (0.2) 20.5 MB_s (0.0) 22.0 MB_s ( 0.1)
patch: 7.3 MB_s (0.1) 10.6 MB_s (0.1) 12.5 MB_s (0.0) 13.1 MB_s ( 0.0)
compile: 25.6 MB_s (0.6) 18.0 MB_s (0.3) 33.9 MB_s (0.2) 36.0 MB_s ( 0.1)
clean: 70.4 MB_s (1.3) 41.7 MB_s (1.8) 539.5 MB_s (3.6) 592.4 MB_s (39.4)
read_tree: 22.1 MB_s (0.0) 21.5 MB_s (0.2) 17.1 MB_s (0.1) 17.8 MB_s ( 0.2)
read_compld: 33.3 MB_s (0.2) 20.4 MB_s (1.1) 21.8 MB_s (0.1) 22.1 MB_s ( 0.1)
delete_tree: 6.5 secs (0.2) 13.5 secs (0.3) 2.7 secs (0.1) 2.5 secs ( 0.0)
stat_tree: 5.2 secs (0.0) 6.7 secs (0.4) 2.4 secs (0.0) 2.2 secs ( 0.0)
stat_compld: 5.7 secs (0.1) 9.6 secs (2.9) 2.5 secs (0.2) 2.5 secs ( 0.0)

A couple of things to note. If you were testing Frank's patches, I
made one additional optimization to his patch, which removed the
orphaned inode handling. This wasn't necessary if you're running
without the journal, I'm not sure if this would be measurable in your
benchmarks, since the inodes that would be getting modified were
probably going to be dirtied and require writeback anyway, but you
might get sightly better numbers with the version of the patch I
ultimately pushed to Linus.

The other thing to note is that in Compilebench's read_tree, ext2 and
ext3 are scoring better than ext4. This is probably related to ext4's
changes in its block/inode allocation hueristics, which is something
that we probably should look at as part of tuning exercises. The
brtfs.boxacle.net benchmarks showed something similar, which I also
would attribute to changes in ext4's allocation policies.

- Ted

このエントリーをはてなブックマークに追加

新機能検証チームから、重点テーマ募集のメールが来た。それはいい。
なぜかその中に

以下の条件を共に、満たすことが前提です。
-顧客にとって役に立つ機能。
(systemtapでテトリスを動かすとかは当然却下 :-P)
[snip]

とか書いてある。
何その狙い打ちのクギ刺し。

stapgames の開発者のみなさんは、顧客に役に立ちます!とか宣言するべきだと思います。
このエントリーをはてなブックマークに追加

昨日、AndrewからCC26件とかいたけど、本日も21件CCされてきた。
合計47件。

明らかに多すぎるので、頑張った成果ではなく、他人からレビュー依頼のCCをうけてるのに
うっかり無視してしまったケースが多そうだ。
うががが。

全然知らねー部分の修正なんかCCされてもレビュー出来ないんじゃよ\(^o^)/
このエントリーをはてなブックマークに追加

今まではスレッドIDが入っていた(POSIX違反)のですが、プロセスIDが入るように変わりました


http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=9cd4fd10437dda6b520cb1410b28f36967a34de8;hp=09bca05c90c639f57aae057e0c28f287e61f5a07

patch descriptionに思いっきり書いてありますが、スレッドIDを期待しているアプリケーションにとっては非互換修正になりますので、ご注意願います。
このエントリーをはてなブックマークに追加

メモ

http://linux.conf.au/wiki/index.php?n=Main.HighPerformanceLinuxBoF

HPC BoF があるらしい。
ちょっと顔だしてみようかな
このエントリーをはてなブックマークに追加

先週 -mmに入ったばかりな気がするが(^-^;

coredump_filterのデフォルト値をブート時のオプションで変えられるようにするパッチ。
2.6.28 でKOSAKI とかいう人がcoredump filterのhugepage対応で非互換修正いれたので、workaround が必要になったらしい。
ほんま、すまんす。

日立さんがRHEL5にバックポートしてくれると期待
このエントリーをはてなブックマークに追加

Andrew MortonがLinusに2.6.29のマージウィンドウ用に送ったパッチが26件ほどCCされてるな。なにをそんなに活動したんだ? >自分
このエントリーをはてなブックマークに追加

Mel Gorman のhugepage関係パッチ。
x86_64だとページサイズが通常ページ(4K)に加えてラージページが二種類(2Mと1G)があるので、/procにpagesizeの項目つけよーぜ。
というパッチ
このエントリーをはてなブックマークに追加

↑このページのトップヘ