プロフィール

kosaki

Author:kosaki
連絡先はコチラ

ブログ検索


最近の記事
最近のコメント
最近のトラックバック
リンク
カテゴリー
月別アーカイブ
RSSフィード
FC2ブログランキング

FC2ブログランキング

[LKML名言集] BIOS書きってのは このエントリーをはてなブックマークに追加

We do not trust BIOS tables, because BIOS writers are invariably totally
incompetent crack-addicted monkeys. If they weren't, they wouldn't be BIOS
writers. QED. And in fact the Apple problem is an _example_ of this BIOS
writer incompetence, not some shining example of them doing something
right.

Linus



超訳：
僕らはBIOSテーブルを信頼してないよ。なぜってBIOS書きってヤツはいっつも
パーペキ無能なコカイン中毒のサルなんだから。もしそうじゃなかったら
彼らはBIOS書きなんかにはならなかったはずさ。証明おわりっ。




・・・それはなにか説明になっているのか？

関連記事
linux | 【2010-05-22(Sat) 10:59:00】 | Trackback:(0) | Comments:(1)

[Linus先生のgit講座] このバグはいつ入ったの？ このエントリーをはてなブックマークに追加

> According to specification
> mkdir d; ln -s d a; open("a/", O_NOFOLLOW | O_RDONLY)
> should return success but currently it did return ELOOP. Fix the code to ignore
> O_NOFOLLOW in case the provided path has trailing slashes. This is a regression
> caused by path lookup cleanup patch series.
>
> CC: [email protected]

Hmm? Is this correct? Isn't the bug introduced in this merge window, and
thus not relevant for stable?



Jan KaraがAl ViroのせいでVFSがこわれたぞって修正パッチをポストしたところ、
Linusから、なんで今回のマージウィンドウでマージされたパッチに対する修正が -stableへの
バックポートが必要なのか。というツッコミが。


On Thu, 13 May 2010, Andrew Morton wrote:
>
> > Ah, you're right! I've seen dates in the patches around December so I
> > automatically thought the series went to 2.6.33 but checking git logs and
> > the actual source code of 2.6.33 it went in later. I'm sorry for the
> > confusion.
>
> Yes, it's a bit tricky (for me, at least) to work out "which kernel version did
> that patch go into" via git.
>
> I just keep lots of kernel trees around and poke about with `patch
> --dry-run'. PITA.



まず、Andrew Mortonがバージョン毎のツリーを抱えて、いちいち patch --dry-run で
当ててみるという自身の力業テクを披露

それをみたLinus大先生による、どうやってバージョン特定を簡単にやるかという
git講座が開始される


What I did to double-check was:

git log fs/namei.c

to find the commit series by Al (obviously, you can do it other ways too,
but that was the easy way). Then, when you find the commit just do

git name-rev 1f36f774b22a0ceb7dd33eca626746c81a97b6a5

which gives us

1f36f774b22a0ceb7dd33eca626746c81a97b6a5 tags/v2.6.34-rc1~195^2

ie that commit is reachable from v2.6.34-rc1, not from any stable kernel.

(Or alternatively, use "git describe", and get "v2.6.33-5088-g1f36f77",
which means that it is v2.6.33 plus 5088 commits).

And as usual, there are other ways. One particularly obscure one is to say

git log --tags --source --author=viro fs/namei.c

which basically says "show only commits by viro in fs/namei.c, start from
all tags, and for each commit, show _which_ tag the commit was reached
from". It's not perfect, but it does it in one go. With "--oneline", you'd
have gotten a listing like

3e297b6 v2.6.34-rc3 Restore LOOKUP_DIRECTORY hint handling in final lookup on open()
781b167 v2.6.34-rc2 Fix a dumb typo - use of & instead of &&
1f36f77 v2.6.34-rc2 Switch !O_CREAT case to use of do_last()
def4af3 v2.6.34-rc2 Get rid of symlink body copying
3866248 v2.6.34-rc2 Finish pulling of -ESTALE handling to upper level in do_filp_open()
806b681 v2.6.34-rc2 Turn do_link spaghetty into a normal loop
10fa8e6 v2.6.34-rc2 Unify exits in O_CREAT handling
9e67f36 v2.6.34-rc2 Kill is_link argument of do_last()
...

so you see into which -rc the different patches from Al went.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html



超訳

git name-rev 1f36f774b22a0ceb7dd33eca626746c81a97b6a5

みたいに、git name-rev [commit-id] ってやれば

1f36f774b22a0ceb7dd33eca626746c81a97b6a5 tags/v2.6.34-rc1~195^2

こんな感じで、v2.6.34-rc1 で入ったって分かる。
もっと簡単にやるには

git log --tags --source --author=viro --oneline fs/namei.c

とかすると、fs/namei.c ファイルに入ったAl Viroの修正一覧がバージョンと共にずらっとでるよ。

3e297b6 v2.6.34-rc3 Restore LOOKUP_DIRECTORY hint handling in final lookup on open()
781b167 v2.6.34-rc2 Fix a dumb typo - use of & instead of &&
1f36f77 v2.6.34-rc2 Switch !O_CREAT case to use of do_last()
def4af3 v2.6.34-rc2 Get rid of symlink body copying
3866248 v2.6.34-rc2 Finish pulling of -ESTALE handling to upper level in do_filp_open()
806b681 v2.6.34-rc2 Turn do_link spaghetty into a normal loop
10fa8e6 v2.6.34-rc2 Unify exits in O_CREAT handling
9e67f36 v2.6.34-rc2 Kill is_link argument of do_last()
...



関連記事
プログラミング | 【2010-05-17(Mon) 11:26:17】 | Trackback:(0) | Comments:(0)

Fedoraゆるせんなー このエントリーをはてなブックマークに追加

Fedora12を使ってるんだけど、yum updateしたら超絶不安定に。
うがー、仕事にならん

関連記事
雑談 | 【2010-05-17(Mon) 05:35:20】 | Trackback:(0) | Comments:(6)

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

http://d.hatena.ne.jp/issei_y/comment?date=20100501&section=1272668964#c

によると、なんか最近のチェスソフトは手動プリフェッチで高速化とかしてるらしい。へー

面白いのはprefetch乱用ソフトの最右翼だったLinuxはprefetchを削除する方向に話を進めていることである。
最近はIntelがプリフェッチを推奨してないのよ。CPU内蔵の自動プリフェッチのほうが石の内部事情に
詳しいので。
なのでインテルコンパイラがプリフェッチ命令を削除してしまうケースがあるというのはおそらく意図的な
ものじゃないかな。

昔のCPUは自動プリフェッチとか弱かったから意味あったんだろうけど・・・


関連記事
プログラミング | 【2010-05-15(Sat) 16:29:28】 | Trackback:(0) | Comments:(2)

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リストに移動しないように論理が変更された。

と、定性的に説明するのも芸がないので、ベンチをとってみた。


測定ソフト
--------------------------
copybench ver 0.1 http://code.google.com/p/copybench/

測定環境
------------------------------------
メモリ： 500M （の環境をcgroupで作った)
コピー対象ファイルサイズ: 1.5G


+ time ./rw_cp /tmp/bigfile /tmp/bigfile2
0.09user 26.19system 0:54.32elapsed 48%CPU (0avgtext+0avgdata 1360maxresident)k
3072832inputs+5674032outputs (0major+106minor)pagefaults 0swaps

+ time ./rw_fadv_cp /tmp/bigfile /tmp/bigfile2
0.08user 25.82system 0:50.83elapsed 50%CPU (0avgtext+0avgdata 1376maxresident)k
3072584inputs+6752512outputs (0major+107minor)pagefaults 0swaps

+ time ./mm_sync_cp /tmp/bigfile /tmp/bigfile2
3.42user 32.59system 0:59.75elapsed 60%CPU (0avgtext+0avgdata 2042576maxresident)k
3073104inputs+3080320outputs (7major+768105minor)pagefaults 0swaps

+ time ./mm_sync_madv_cp /tmp/bigfile /tmp/bigfile2
3.54user 32.91system 1:00.02elapsed 60%CPU (0avgtext+0avgdata 2041536maxresident)k
3072856inputs+6056488outputs (2major+768103minor)pagefaults 0swaps

+ time ./mw_cp /tmp/bigfile /tmp/bigfile2
0.00user 28.39system 0:53.09elapsed 53%CPU (0avgtext+0avgdata 1380608maxresident)k
3072832inputs+4456448outputs (3major+384101minor)pagefaults 0swaps

+ time ./mw_madv_cp /tmp/bigfile /tmp/bigfile2
0.00user 27.91system 0:52.49elapsed 53%CPU (0avgtext+0avgdata 1021680maxresident)k
3072856inputs+5076432outputs (1major+384103minor)pagefaults 0swaps


以前は mm_sync_cp (readもwriteもmmapで、madviseなし)だけelapsが二倍遅いとかザラだったので、
結構いい感じ。

しかし、いまだに多くのツールでmmapのほうが速いと盲目的に信じているのは困りものである。ほむり。

関連記事
linux | 【2010-05-02(Sun) 00:27:57】 | Trackback:(0) | Comments:(0)
Copyright © 革命の日々！ All Rights Reserved. skin：cuteblog
  1. 無料アクセス解析