Could we get that, as PeterZ has suggested, as a trace_option
column in the 'trace' file? It would be default off for
non-latency tracers, with latency tracing plugins turning it on
by default. Would that work?
Ingo
PeterZ ってメチャクチャ強そうじゃね？
- 関連記事
-
- cache pollution aware __copy_from_user_ll() ふたたび (2009/03/01)
- プールから出てくる漢、Peter Zijlstra (2009/02/27)
- Andrewからバグを振られる (2009/02/27)
http://bugzilla.kernel.org/show_bug.cgi?id=12785
・・・が、lennyって2.6.26じゃん。オレのコードは入ってないよー
と駄々をこねてみる。
Ｄｅｂｉａｎユーザーのみなさんで、同じ現象にあっている人がいたら連絡をください。
くわしい現象とかヒアリングしたいです。
・・・が、lennyって2.6.26じゃん。オレのコードは入ってないよー
と駄々をこねてみる。
Ｄｅｂｉａｎユーザーのみなさんで、同じ現象にあっている人がいたら連絡をください。
くわしい現象とかヒアリングしたいです。
- 関連記事
-
- プールから出てくる漢、Peter Zijlstra (2009/02/27)
- Andrewからバグを振られる (2009/02/27)
- 第10回 The Linux Foundation Japan Symposium で講演してきました (2009/02/27)
資料はこちらから
http://jp.linuxfoundation.org/?q=node/163
アンケート結果は５点満点で４．５と歴代の発表のなかでもトップレベルだそうな。よかったよかった。
しかし、社内評価は低いのであった。
http://jp.linuxfoundation.org/?q=node/163
アンケート結果は５点満点で４．５と歴代の発表のなかでもトップレベルだそうな。よかったよかった。
しかし、社内評価は低いのであった。
- 関連記事
-
- Andrewからバグを振られる (2009/02/27)
- 第10回 The Linux Foundation Japan Symposium で講演してきました (2009/02/27)
- [email protected] MLを作ることになった (2009/02/24)
いろいろとトレース周りの議論が混迷しているので、整理を図ってみた。
うまくいくかどうか。。。
ディスカッション・スキルが低いやつらが多いんだよなぁー
うまくいくかどうか。。。
ディスカッション・スキルが低いやつらが多いんだよなぁー
- 関連記事
-
- 第10回 The Linux Foundation Japan Symposium で講演してきました (2009/02/27)
- [email protected] MLを作ることになった (2009/02/24)
- 発表の予行演習ｵﾜﾀ (2009/02/23)
二重の意味で。
ボロクソに言われたので必死扱いて資料修正中
ボロクソに言われたので必死扱いて資料修正中
- 関連記事
という記事を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時のファイルシステムのアライメントとか、mkfs時のstripe-widthとか、LVMのメタデータサイズとか）
・でもIntelも将来のSSDでもっと進んだアルゴリズムを搭載するって言ってるよ
結局Windows Server2008と同等にするよって言ってるだけな気がしなくもない。
追記： なんか、さっそくbtrfs MLでうちらも同じ事しなくてよいの？って質問がとんでるな
追記２： なぜか512byteを512Kと書いていた。あほすぎる
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時のファイルシステムのアライメントとか、mkfs時のstripe-widthとか、LVMのメタデータサイズとか）
・でもIntelも将来のSSDでもっと進んだアルゴリズムを搭載するって言ってるよ
結局Windows Server2008と同等にするよって言ってるだけな気がしなくもない。
追記： なんか、さっそくbtrfs MLでうちらも同じ事しなくてよいの？って質問がとんでるな
追記２： なぜか512byteを512Kと書いていた。あほすぎる
- 関連記事
-
- 発表の予行演習ｵﾜﾀ (2009/02/23)
- Aligning filesystems to an SSD’s erase block size (2009/02/22)
- [RFC][PATCH 0/4] Memory controller soft limit patches (v2) (2009/02/17)
> OK, so without text_poke, how does it deal with kernel with text pages
> marked read-only after boot ?
Actually, we cheat. If DYNAMIC_FTRACE is configured in, we do not set the
text sections to read only. But if this needs to be fixed, we can easily
change it so that before we do the convesion, we set all text back to
write and after the conversion we set it back to read. The conversion
itself is done via stop_machine, so we do not need to worry about other
things going on.
-- Steve
とりあえず、英語でもチートって言ってもいいということは分かった。
しかし、この仕様だとDYNAMIC_FTRACEは本番環境ではつかえんのぅ
- 関連記事
-
- [英語] artifact (2009/03/01)
- [英語] cheat (2009/02/18)
- [英語] I'm afraid (2009/02/18)
http://www.pbwritingcenter.com/qa/20.html
ようするにsorryだが、未来のことはこれで言わない方がよいらしい
ようするにsorryだが、未来のことはこれで言わない方がよいらしい
- 関連記事
-
- [英語] cheat (2009/02/18)
- [英語] I'm afraid (2009/02/18)
- from now on (2009/02/13)
96 ：以下、名無しにかわりましてVIPがお送りします：2009/02/05(木) 02:39:25.12 ID:4ZSXuCJS0
グリフィスが大帝に圧勝 しかしミッドランドの人は全員悪魔になる
↓
ガッツが悪魔の鎧を完全克服 人の頭脳に悪魔の力をもった悪魔人間に
↓
グリフィス軍対ガッツ軍が戦う それ以外の人類滅亡
↓
戦争終結 グリフィスはなんと両性具有だった！
↓
天使っぽいグリフィスと下半身ちょんぎれたガッツが一緒にいるシーンで完
↓
次回作バイオレンス・ガッツをお楽しみに！
- 関連記事
-
- 草なぎ君が逮捕されたらしい (2009/04/23)
- ベルセルクの今後の展開を書くよ (2009/02/17)
- 詳しく答えるなら (2009/01/13)
をレビューした。
死ねばいいのに、とか思ったパッチは久しぶり。
メモリー系のメンテナが速度にまったく無関心なのは問題だよな
死ねばいいのに、とか思ったパッチは久しぶり。
メモリー系のメンテナが速度にまったく無関心なのは問題だよな
- 関連記事
-
- Aligning filesystems to an SSD’s erase block size (2009/02/22)
- [RFC][PATCH 0/4] Memory controller soft limit patches (v2) (2009/02/17)
- SLQBの性能がSLUBに負けているようです (2009/02/17)
SPECINT（HPC用ベンチマーク）だとSLUBのほうが性能がよいらしい。
これでますますSLAB戦争の行方は混沌としてきましたな
・・・ところで、SPECINTの性能って勝手に公開していいんだっけ？
これでますますSLAB戦争の行方は混沌としてきましたな
・・・ところで、SPECINTの性能って勝手に公開していいんだっけ？
Subject: Re: [patch] SLQB slab allocator (try 2)
From: Mel Gorman
To: Nick Piggin
Cc: Pekka Enberg,
Nick Piggin,
Linux Memory Management List,
Linux Kernel Mailing List,
Andrew Morton,
Lin Ming,
"Zhang, Yanmin",
Christoph Lameter
Date: Mon, 16 Feb 2009 18:42:00 +0000
In-Reply-To: <[email protected]>
Slightly later than hoped for, but here are the results of the profile
run between the different slab allocators. It also includes information on
the performance on SLUB with the allocator pass-thru logic reverted by commit
http://git.kernel.org/?p=linux/kernel/git/penberg/slab-2.6.git;a=commitdiff;h=97a4871761e735b6f1acd3bc7c3bac30dae3eab9
..
All the profiles are in a tar stored at
http://www.csn.ul.ie/~mel/postings/slXb-20090213/ . The layout of it is as
follows
o hydra is the x86-64 machine
o powyah is the ppc64 machine
o the next level of directories is for each benchmark
o speccpu06/profile contains spec config files. gen-m64base.cfg was used
o The result/ directory contains three types of files
procinfo-before-* Proc files and slabinfo before a benchmark
procinfo-after-* Proc files after
OP.* Oprofile output
The files are indexed 001, 002 etc and are as follows
001 slab
002 slub-default
003 slub-minorder (max_order=1, min_objects=1)
004 slqb
005 slub-revert-passthru
o The sysbench-run2 directories are named based on the allocator tested
o The sysbench contain noprofile, profile and fine-profile directories
fine-profile is probably of the most interest. There are files named
oprofile-THREAD_COUNT-report.txt where THREAD_COUNT is in the range 1-16.
I haven't done much digging in here yet. Between the large page bug and
other patches in my inbox, I haven't had the chance yet but that doesn't
stop anyone else taking a look.
I'm reposting the performance as SLUB and SLQB had to be rebuilt with profile
stats enabled which potentially changed the result slightly.
x86-64 speccpu performance ratios
=================================
Integer tests
SPEC test slab slub slub-min slub-rvrt slqb
400.perlbench 1.0000 1.0472 1.0118 1.0393 1.0000
401.bzip2 1.0000 1.0071 0.9970 1.0041 1.0000
403.gcc 1.0000 0.9579 0.9952 0.9034 0.9588
429.mcf 1.0000 1.0089 0.9933 0.9376 0.9959
445.gobmk 1.0000 0.9881 1.0040 0.9894 0.9947
456.hmmer 1.0000 0.9911 1.1039 0.9911 0.9940
458.sjeng 1.0000 0.9958 0.9622 0.9691 0.9632
462.libquantum 1.0000 1.0576 0.9974 1.0817 1.0547
464.h264ref 1.0000 1.0230 1.0295 1.0165 1.0279
471.omnetpp 1.0000 1.0038 0.9511 0.9626 0.9557
473.astar 1.0000 0.9811 0.9957 0.9989 0.9957
483.xalancbmk 1.0000 1.0889 1.0135 1.0060 1.0715
---------------
specint geomean 1.0000 1.0119 1.0039 0.9907 1.0004
Floating Point Tests
SPEC test slab slub slub-min slub-rvrt slqb
410.bwaves 1.0000 1.0047 0.8369 0.8366 0.8366
416.gamess 1.0000 1.0038 1.0015 0.9977 1.0046
433.milc 1.0000 1.1416 1.1187 1.0182 1.1329
434.zeusmp 1.0000 1.0847 0.9991 1.0009 0.9974
435.gromacs 1.0000 1.0652 1.0000 1.0652 0.9989
436.cactusADM 1.0000 1.0057 0.9974 1.0979 1.0021
437.leslie3d 1.0000 1.0438 1.0387 1.0034 0.9919
444.namd 1.0000 1.0000 0.9713 0.9947 1.0027
447.dealII 1.0000 1.0000 0.9986 1.0071 0.9986
450.soplex 1.0000 0.9627 0.8958 1.0169 1.0028
453.povray 1.0000 0.9971 0.9457 0.9508 1.0029
454.calculix 1.0000 0.9994 0.9612 1.0012 0.9994
459.GemsFDTD 1.0000 1.0035 0.9094 1.0057 1.0014
465.tonto 1.0000 1.0155 1.0010 1.0000 1.0010
470.lbm 1.0000 1.2551 1.2406 1.2613 1.0008
481.wrf 1.0000 0.9971 0.9514 0.9527 0.9501
482.sphinx3 1.0000 1.0045 0.9994 1.0083 0.9994
---------------
specfp geomean 1.0000 1.0323 0.9886 1.0098 0.9941
x86-64 sysbench performance ratios
==================================
Client slab slub slub-min slub-rvrt slqb
1 1.0000 1.0390 0.9698 1.0396 0.9803
2 1.0000 1.0080 1.0008 0.9986 0.9967
3 1.0000 1.0132 1.0032 0.9904 0.9947
4 1.0000 1.0222 1.0059 0.9898 0.9914
5 1.0000 1.0025 1.0144 0.9929 0.9869
6 1.0000 0.9959 1.0118 1.0082 0.9974
7 1.0000 1.0008 0.9805 0.9676 0.9829
8 1.0000 0.9878 0.9875 0.9702 0.9850
9 1.0000 1.0126 1.0322 0.9894 0.9966
10 1.0000 0.9984 0.9968 0.9947 1.0265
11 1.0000 1.0028 1.0086 0.9922 1.0215
12 1.0000 1.0044 1.0044 0.9910 0.9965
13 1.0000 0.9940 0.9929 0.9854 0.9849
14 1.0000 0.9997 1.0127 0.9892 0.9870
15 1.0000 0.9984 1.0044 0.9905 1.0029
16 1.0000 0.9912 0.9878 1.0034 0.9912
Geo. mean 1.0000 1.0044 1.0007 0.9932 0.9951
ppc64 speccpu performance ratios
================================
Integer tests
SPEC test slab slub slub-mi slub-rvrt slqb
400.perlbench 1.0000 1.0008 0.9954 1.0008 1.0008
401.bzip2 1.0000 0.9993 0.9980 0.9973 1.0000
403.gcc 1.0000 0.9983 0.9991 0.9975 0.9983
429.mcf 1.0000 1.0004 0.9954 1.0000 1.0004
445.gobmk 1.0000 1.0009 1.0028 1.0009 1.0018
456.hmmer 1.0000 1.0054 1.0040 0.9993 0.9987
458.sjeng 1.0000 0.9976 1.0006 1.0006 0.9976
462.libquantum 1.0000 1.0039 1.0051 1.0032 1.0039
464.h264ref 1.0000 0.9958 0.9988 0.9988 0.9994
471.omnetpp 1.0000 0.9935 0.9859 0.9886 0.9913
473.astar 1.0000 0.9978 1.0000 0.9978 1.0022
483.xalancbmk 1.0000 1.0008 1.0017 1.0000 1.0017
---------------
specint geomean 1.0000 0.9995 0.9989 0.9987 0.9997
Floating Point Tests
SPEC test slab slub slub-min slub-rvrt slqb
410.bwaves 1.0000 0.9135 1.0016 0.9851 0.9439
416.gamess 1.0000 0.9990 0.9956 0.9922 0.9942
433.milc 1.0000 1.0018 1.0030 1.0036 1.0036
434.zeusmp 1.0000 1.0000 1.0008 0.9984 1.0008
435.gromacs 1.0000 0.9992 0.9962 0.9970 0.9985
436.cactusADM 1.0000 0.9914 1.0029 0.9931 0.9931
437.leslie3d 1.0000 1.0016 1.0027 1.0000 1.0019
444.namd 1.0000 0.9834 0.9976 0.9976 0.9904
447.dealII 1.0000 1.0045 1.0018 1.0018 1.0027
450.soplex 1.0000 0.9981 0.9953 0.9943 0.9981
453.povray 1.0000 0.9963 1.0037 0.9927 0.9083
454.calculix 1.0000 0.9980 0.9992 0.9968 0.9988
459.GemsFDTD 1.0000 0.9991 0.9981 0.9994 0.9981
465.tonto 1.0000 1.0024 0.9923 0.9976 1.0000
470.lbm 1.0000 1.0000 0.9988 0.9988 1.0000
481.wrf 1.0000 0.9981 1.0005 0.9971 0.9971
482.sphinx3 1.0000 0.9983 0.9970 0.9970 1.0000
---------------
specfp geomean 1.0000 0.9930 0.9992 0.9966 0.9897
ppc64 sysbench performance ratios
==================================
Client slab slub slub-min slub-rvrt slqb
1 1.0000 0.9723 0.9876 0.9882 0.9675
2 1.0000 0.9878 1.0010 0.9901 0.9586
3 1.0000 0.9732 1.0025 0.9915 0.9492
4 1.0000 0.9680 1.0021 1.0023 0.9803
5 1.0000 0.9762 0.9945 0.9861 0.9780
6 1.0000 0.9773 1.0039 0.9976 0.9774
7 1.0000 0.9699 1.0051 0.9895 0.9708
8 1.0000 0.9789 1.0041 0.9864 0.9734
9 1.0000 0.9622 0.9951 0.9790 0.9627
10 1.0000 0.9688 1.0024 0.9621 0.9708
11 1.0000 0.9701 1.0033 0.9872 0.9706
12 1.0000 0.9698 0.9999 0.9871 0.9728
13 1.0000 0.9677 0.9978 0.9816 0.9695
14 1.0000 0.9729 1.0067 0.9903 0.9726
15 1.0000 0.9756 1.0027 0.9906 0.9730
16 1.0000 0.9655 0.9975 0.9804 0.9668
Geo. mean 1.0000 0.9722 1.0004 0.9868 0.9696
Cache misses
============
Based on the profiles, here are the cache profiles of speccpu at least. I
ran out of time for writing a reporting script for sysbench but all the
necessary data is in the tar. Remember that the ratios are of improvements
so a ration of 1.0463 implies 4.63% fewer cache misses than SLAB.
x86-64 speccpu cache-miss improvements
======================================
SPEC test slab slub slub-min slub-rvrt slqb
perlbench 1.0000 1.0463 0.9861 1.0539 1.0147
bzip2 1.0000 1.0091 1.0051 1.0110 0.9925
gcc 1.0000 0.9579 0.9610 0.8922 0.9959
mcf 1.0000 1.0069 0.9970 0.9470 0.9786
gobmk 1.0000 0.9873 0.9942 0.9953 1.0032
hmmer 1.0000 0.7456 0.9739 1.0048 0.9373
sjeng 1.0000 1.0289 1.0154 1.1512 0.9695
libquantum 1.0000 1.0348 1.0010 1.0508 0.9971
h264ref 1.0000 1.0600 1.1158 1.1002 1.1486
omnetpp 1.0000 1.0014 0.9650 0.9687 0.9566
astar 1.0000 0.9867 1.0017 1.0045 1.0016
xalancbmk 1.0000 1.0935 1.0834 1.0090 1.0361
---------
specint geomean 1.0000 0.9925 1.0074 1.0136 1.0014
milc 1.0000 1.1239 1.1935 1.1025 1.1002
lbm 1.0000 1.2181 1.0002 1.2219 1.1871
sphinx3 1.0000 1.2743 1.0039 1.0107 1.2692
bwaves 1.0000 1.0145 0.8063 0.8042 0.8041
gamess 1.0000 1.0120 0.9974 0.9685 0.9914
zeusmp 1.0000 1.0769 0.9998 1.0013 1.0032
leslie3d 1.0000 1.0276 0.9558 1.0032 0.9901
GemsFDTD 1.0000 1.0052 1.0044 1.0039 0.9076
tonto 1.0000 0.9967 0.9778 0.9856 0.9887
gromacs 1.0000 1.0570 1.0017 1.0563 1.0008
cactusADM 1.0000 1.0117 1.0060 1.0786 0.9999
calculix 1.0000 1.0049 1.0022 1.0003 0.9469
wrf 1.0000 0.8324 0.9552 0.9675 0.9646
namd 1.0000 0.9892 1.0467 0.9985 0.9930
dealII 1.0000 1.0240 1.0105 1.0268 1.0097
soplex 1.0000 0.9731 1.0088 1.0131 0.9065
povray 1.0000 1.0100 1.0080 0.9757 0.9532
---------
specfp geomean 1.0000 1.0341 0.9962 1.0097 0.9959
ppc64 speccpu cache-miss improvements
=====================================
SPEC test slab slub slub-min slub-rvrt slqb
perlbench 1.0000 1.0168 1.0065 1.0210 0.9777
bzip2 1.0000 1.0053 1.0304 0.9894 0.9885
gcc 1.0000 1.0008 1.0051 0.9974 1.0040
mcf 1.0000 0.9783 1.0045 0.9856 0.9717
gobmk 1.0000 1.0123 1.0197 1.0256 1.0274
hmmer 1.0000 0.9936 0.9741 0.9829 0.9961
sjeng 1.0000 0.9980 0.9839 1.0066 1.0197
libquantum 1.0000 1.0199 1.0020 0.9916 0.9752
h264ref 1.0000 1.0177 1.0064 1.0167 1.0258
omnetpp 1.0000 0.9904 0.9940 1.0002 0.9572
astar 1.0000 0.9926 1.0115 0.9946 0.9900
xalancbmk 1.0000 1.0131 1.0133 1.0090 1.0244
---------
specint geomean 1.0000 1.0032 1.0042 1.0016 0.9962
milc 1.0000 1.0140 1.0307 1.0317 1.0141
lbm 1.0000 0.9966 0.9971 1.0201 0.9811
sphinx3 1.0000 0.9904 0.9844 0.9871 0.9982
bwaves 1.0000 1.0106 1.0380 1.0071 1.0203
gamess 1.0000 1.0475 1.0286 1.0136 1.0194
zeusmp 1.0000 1.0274 1.0152 1.0284 1.0214
leslie3d 1.0000 0.9788 0.9640 1.0118 0.9583
GemsFDTD 1.0000 1.0236 1.0110 1.0201 0.9936
tonto 1.0000 1.0591 0.9458 0.9342 1.0341
gromacs 1.0000 1.0159 1.0037 0.9749 0.9904
cactusADM 1.0000 0.9946 1.0000 0.9914 1.0201
calculix 1.0000 1.0206 1.0313 1.0363 1.0331
wrf 1.0000 1.0222 1.0096 1.0606 1.0253
namd 1.0000 0.9862 0.9773 0.9557 0.9744
dealII 1.0000 1.0135 0.9904 1.0333 1.0205
soplex 1.0000 1.0213 1.0081 0.9998 0.9922
povray 1.0000 1.0201 1.0016 1.0419 1.0575
--------
specfp geomean 1.0000 1.0140 1.0019 1.0082 1.0088
Glancing through, it would appear that slub with default settings is often the
cache-friendlist, but it suffered badly on hmmer on the x86-64, probably an
accident of layout. While its cache usage for lbm and sphinx were drastically
improved for slub, it didn't translate into significantly better performance.
It's difficult to conclude anything from the cache figures other than no
allocator is obviously far worse than slab in terms of cache usage.
- 関連記事
-
- [RFC][PATCH 0/4] Memory controller soft limit patches (v2) (2009/02/17)
- SLQBの性能がSLUBに負けているようです (2009/02/17)
- 海外さんが珍しく計算を間違っていた件について (2009/02/17)
http://lists.sourceforge.jp/mailman/archives/jsosug-users/2009-February/000068.html
で、TOMOYOのメインライン化が７月頃と書いているが計算間違いだったようだ
2.6.29-rc5 今（２月）
2.6.30-rc1 でnext入り（４月）
2.6.31-rc1 でlinusツリー入り（７月）
2.6.31 リリース（１０月）
となるので、１０月が正しい。ちょうどkernel summit, JLSの時期に重なるはずで、あるいみベストタイミング？
いや、ただの予測に正しいとかって変だけど。
で、孫引きしたと思われる以下の報道も時期が間違っていて、裏をとっていないのがバレてしまっている。
http://itpro.nikkeibp.co.jp/article/NEWS/20090212/324657/?ST=oss
で、TOMOYOのメインライン化が７月頃と書いているが計算間違いだったようだ
2.6.29-rc5 今（２月）
2.6.30-rc1 でnext入り（４月）
2.6.31-rc1 でlinusツリー入り（７月）
2.6.31 リリース（１０月）
となるので、１０月が正しい。ちょうどkernel summit, JLSの時期に重なるはずで、あるいみベストタイミング？
いや、ただの予測に正しいとかって変だけど。
で、孫引きしたと思われる以下の報道も時期が間違っていて、裏をとっていないのがバレてしまっている。
http://itpro.nikkeibp.co.jp/article/NEWS/20090212/324657/?ST=oss
- 関連記事
-
- SLQBの性能がSLUBに負けているようです (2009/02/17)
- 海外さんが珍しく計算を間違っていた件について (2009/02/17)
- /sys/kernel/debug/kernel_page_tables (2009/02/16)
なるファイルがいつの間にか出来ていた。
気づかなかった・・・・
カーネルのpteマッピングをダンプしてくれる。うーん、こういう機能をx86限定にするなよな。
フォーマットは以下で
{start_addr}-{end_addr} size usr rw flags level
フラグの意味は以下（詳しくはx86のプロセッサマニュアルをどぞ）
USR: リング０じゃない
RW: writable mapping
ro: read only mapping
PWT: write through
PCD: page cache disabled
PSE: PSEフラグがON。ようするにラージページ
pat: PATページ
GLB: global page、コンテキストスイッチでTLBフラッシュされないページ。普通あらゆるカーネルページでON。（何もマップされてない部分をのぞく）
NX: Not Execute フラグがON
x: 〃がOFF
levelは以下の種類が cr3, pgd, pmd, pte。まあ、x86の定義通り
以下、気づいたこと。
/proc/vmallocinfoとつきあわせると、vmallocエリアの詳細がもっとわかるが、PCDが大量にあるのは、ACPIまわりのマッピングだから。あと、vmallocの仕様として、１ページ分余分に仮想空間を確保するので、いちいち4kずつ穴が空いていて見にくいね。
気づかなかった・・・・
カーネルのpteマッピングをダンプしてくれる。うーん、こういう機能をx86限定にするなよな。
フォーマットは以下で
{start_addr}-{end_addr} size usr rw flags level
フラグの意味は以下（詳しくはx86のプロセッサマニュアルをどぞ）
USR: リング０じゃない
RW: writable mapping
ro: read only mapping
PWT: write through
PCD: page cache disabled
PSE: PSEフラグがON。ようするにラージページ
pat: PATページ
GLB: global page、コンテキストスイッチでTLBフラッシュされないページ。普通あらゆるカーネルページでON。（何もマップされてない部分をのぞく）
NX: Not Execute フラグがON
x: 〃がOFF
levelは以下の種類が cr3, pgd, pmd, pte。まあ、x86の定義通り
% sudo cat /sys/kernel/debug/kernel_page_tables
---[ User Space ]---
0x(null)-0xffff800000000000 16777088T pgd
---[ Kernel Space ]---
0xffff800000000000-0xffff880000000000 8T pgd
---[ Low Kernel Mapping ]---
0xffff880000000000-0xffff880000400000 4M RW PSE GLB x pmd
0xffff880000400000-0xffff880000589000 1572K RW GLB x pte
0xffff880000589000-0xffff88000076c000 1932K ro GLB x pte
0xffff88000076c000-0xffff880000800000 592K RW GLB x pte
0xffff880000800000-0xffff880040000000 1016M RW PSE GLB x pmd
0xffff880040000000-0xffff88007fe00000 1022M RW PSE GLB NX pmd
0xffff88007fe00000-0xffff88007fee0000 896K RW GLB NX pte
0xffff88007fee0000-0xffff880080000000 1152K pte
0xffff880080000000-0xffff888000000000 510G pud
0xffff888000000000-0xffffc20000000000 58880G pgd
---[ vmalloc() Area ]---
0xffffc20000000000-0xffffc20000001000 4K RW PCD GLB NX pte
0xffffc20000001000-0xffffc20000003000 8K pte
0xffffc20000003000-0xffffc20000203000 2M RW GLB NX pte
0xffffc20000203000-0xffffc20000205000 8K pte
0xffffc20000205000-0xffffc20000305000 1M RW GLB NX pte
0xffffc20000305000-0xffffc20000307000 8K pte
0xffffc20000307000-0xffffc20000309000 8K RW GLB NX pte
0xffffc20000309000-0xffffc2000030c000 12K pte
0xffffc2000030c000-0xffffc2000030d000 4K RW PCD GLB NX pte
0xffffc2000030d000-0xffffc20000310000 12K pte
0xffffc20000310000-0xffffc20000314000 16K RW PCD GLB NX pte
0xffffc20000314000-0xffffc20000316000 8K pte
0xffffc20000316000-0xffffc20000317000 4K RW PCD GLB NX pte
0xffffc20000317000-0xffffc2000031a000 12K pte
0xffffc2000031a000-0xffffc2000031b000 4K RW PCD GLB NX pte
0xffffc2000031b000-0xffffc2000031e000 12K pte
0xffffc2000031e000-0xffffc2000031f000 4K RW PCD GLB NX pte
0xffffc2000031f000-0xffffc20000322000 12K pte
0xffffc20000322000-0xffffc20000323000 4K RW PCD GLB NX pte
0xffffc20000323000-0xffffc20000325000 8K pte
0xffffc20000325000-0xffffc20000327000 8K RW GLB NX pte
0xffffc20000327000-0xffffc2000032a000 12K pte
0xffffc2000032a000-0xffffc2000032b000 4K RW PCD GLB NX pte
0xffffc2000032b000-0xffffc2000032e000 12K pte
0xffffc2000032e000-0xffffc2000032f000 4K RW PCD GLB NX pte
0xffffc2000032f000-0xffffc20000332000 12K pte
0xffffc20000332000-0xffffc20000333000 4K RW PCD GLB NX pte
0xffffc20000333000-0xffffc20000336000 12K pte
0xffffc20000336000-0xffffc20000337000 4K RW PCD GLB NX pte
0xffffc20000337000-0xffffc2000033a000 12K pte
0xffffc2000033a000-0xffffc2000033b000 4K RW PCD GLB NX pte
0xffffc2000033b000-0xffffc2000033e000 12K pte
0xffffc2000033e000-0xffffc2000033f000 4K RW PCD GLB NX pte
0xffffc2000033f000-0xffffc20000340000 4K pte
0xffffc20000340000-0xffffc20000342000 8K RW PCD GLB NX pte
0xffffc20000342000-0xffffc20000344000 8K pte
0xffffc20000344000-0xffffc20000345000 4K RW PCD GLB NX pte
0xffffc20000345000-0xffffc20000348000 12K pte
0xffffc20000348000-0xffffc20000349000 4K RW PCD GLB NX pte
0xffffc20000349000-0xffffc2000034c000 12K pte
0xffffc2000034c000-0xffffc2000034d000 4K RW PCD GLB NX pte
0xffffc2000034d000-0xffffc20000350000 12K pte
0xffffc20000350000-0xffffc20000351000 4K RW PCD GLB NX pte
0xffffc20000351000-0xffffc20000354000 12K pte
0xffffc20000354000-0xffffc20000355000 4K RW PCD GLB NX pte
0xffffc20000355000-0xffffc20000358000 12K pte
0xffffc20000358000-0xffffc20000359000 4K RW PCD GLB NX pte
0xffffc20000359000-0xffffc2000035b000 8K pte
0xffffc2000035b000-0xffffc2000035f000 16K RW GLB NX pte
0xffffc2000035f000-0xffffc20000361000 8K pte
0xffffc20000361000-0xffffc20000364000 12K RW GLB NX pte
0xffffc20000364000-0xffffc20000366000 8K pte
0xffffc20000366000-0xffffc20000367000 4K RW GLB NX pte
0xffffc20000367000-0xffffc20000369000 8K pte
0xffffc20000369000-0xffffc20000374000 44K RW GLB NX pte
0xffffc20000374000-0xffffc20000376000 8K pte
0xffffc20000376000-0xffffc20000377000 4K RW PCD GLB NX pte
0xffffc20000377000-0xffffc2000037a000 12K pte
0xffffc2000037a000-0xffffc2000037b000 4K RW PCD GLB NX pte
0xffffc2000037b000-0xffffc2000037e000 12K pte
0xffffc2000037e000-0xffffc2000037f000 4K RW PCD GLB NX pte
0xffffc2000037f000-0xffffc20000380000 4K pte
0xffffc20000380000-0xffffc20000880000 5M RW PCD GLB NX pte
0xffffc20000880000-0xffffc20000882000 8K pte
0xffffc20000882000-0xffffc20000902000 512K RW GLB NX pte
0xffffc20000902000-0xffffc20000904000 8K pte
0xffffc20000904000-0xffffc20000d04000 4M RW GLB NX pte
0xffffc20000d04000-0xffffc20000d06000 8K pte
0xffffc20000d06000-0xffffc20001186000 4608K RW GLB NX pte
0xffffc20001186000-0xffffc20001188000 8K pte
0xffffc20001188000-0xffffc20001189000 4K RW PCD GLB NX pte
0xffffc20001189000-0xffffc2000120a000 516K pte
0xffffc2000120a000-0xffffc2000120c000 8K RW GLB NX pte
0xffffc2000120c000-0xffffc200012e0000 848K pte
0xffffc200012e0000-0xffffc200012f0000 64K RW PCD GLB NX pte
0xffffc200012f0000-0xffffc20001300000 64K pte
0xffffc20001300000-0xffffc20001800000 5M RW PCD GLB NX pte
0xffffc20001800000-0xffffc20001933000 1228K pte
0xffffc20001933000-0xffffc20001a33000 1M RW GLB NX pte
0xffffc20001a33000-0xffffc20001c00000 1844K pte
0xffffc20001c00000-0xffffc20040000000 996M pmd
0xffffc20040000000-0xffffc28000000000 511G pud
0xffffc28000000000-0xffffe20000000000 32256G pgd
---[ Vmemmap ]---
0xffffe20000000000-0xffffe20003400000 52M RW PSE GLB NX pmd
0xffffe20003400000-0xffffe20040000000 972M pmd
0xffffe20040000000-0xffffe28000000000 511G pud
0xffffe28000000000-0xffffff8000000000 29T pgd
0xffffff8000000000-0xffffffff80000000 510G pud
---[ High Kernel Mapping ]---
0xffffffff80000000-0xffffffff81000000 16M pmd
0xffffffff81000000-0xffffffff81200000 2M RW PSE GLB x pmd
0xffffffff81200000-0xffffffff81389000 1572K RW GLB x pte
0xffffffff81389000-0xffffffff8156c000 1932K ro GLB NX pte
0xffffffff8156c000-0xffffffff81600000 592K RW GLB x pte
0xffffffff81600000-0xffffffff82200000 12M RW PSE GLB x pmd
0xffffffff82200000-0xffffffffa0000000 478M pmd
---[ Modules ]---
0xffffffffa0000000-0xffffffffa0007000 28K RW GLB x pte
0xffffffffa0007000-0xffffffffa0009000 8K pte
0xffffffffa0009000-0xffffffffa000b000 8K RW GLB x pte
0xffffffffa000b000-0xffffffffa000c000 4K pte
0xffffffffa000c000-0xffffffffa000e000 8K RW GLB x pte
0xffffffffa000e000-0xffffffffa0010000 8K pte
0xffffffffa0010000-0xffffffffa0011000 4K RW GLB x pte
0xffffffffa0011000-0xffffffffa0013000 8K pte
0xffffffffa0013000-0xffffffffa0015000 8K RW GLB x pte
0xffffffffa0015000-0xffffffffa0017000 8K pte
0xffffffffa0017000-0xffffffffa0018000 4K RW GLB x pte
0xffffffffa0018000-0xffffffffa001a000 8K pte
0xffffffffa001a000-0xffffffffa001f000 20K RW GLB x pte
0xffffffffa001f000-0xffffffffa0020000 4K pte
0xffffffffa0020000-0xffffffffa0026000 24K RW GLB x pte
0xffffffffa0026000-0xffffffffa0028000 8K pte
0xffffffffa0028000-0xffffffffa002a000 8K RW GLB x pte
0xffffffffa002a000-0xffffffffa002b000 4K pte
0xffffffffa002b000-0xffffffffa002c000 4K RW GLB x pte
0xffffffffa002c000-0xffffffffa002e000 8K pte
0xffffffffa002e000-0xffffffffa002f000 4K RW GLB x pte
0xffffffffa002f000-0xffffffffa0031000 8K pte
0xffffffffa0031000-0xffffffffa0033000 8K RW GLB x pte
0xffffffffa0033000-0xffffffffa0038000 20K pte
0xffffffffa0038000-0xffffffffa003d000 20K RW GLB x pte
0xffffffffa003d000-0xffffffffa003f000 8K pte
0xffffffffa003f000-0xffffffffa0041000 8K RW GLB x pte
0xffffffffa0041000-0xffffffffa0042000 4K pte
0xffffffffa0042000-0xffffffffa0044000 8K RW GLB x pte
0xffffffffa0044000-0xffffffffa0049000 20K pte
0xffffffffa0049000-0xffffffffa004f000 24K RW GLB x pte
0xffffffffa004f000-0xffffffffa0051000 8K pte
0xffffffffa0051000-0xffffffffa0054000 12K RW GLB x pte
0xffffffffa0054000-0xffffffffa0056000 8K pte
0xffffffffa0056000-0xffffffffa005a000 16K RW GLB x pte
0xffffffffa005a000-0xffffffffa005f000 20K pte
0xffffffffa005f000-0xffffffffa007b000 112K RW GLB x pte
0xffffffffa007b000-0xffffffffa0080000 20K pte
0xffffffffa0080000-0xffffffffa0085000 20K RW GLB x pte
0xffffffffa0085000-0xffffffffa0087000 8K pte
0xffffffffa0087000-0xffffffffa008c000 20K RW GLB x pte
0xffffffffa008c000-0xffffffffa008e000 8K pte
0xffffffffa008e000-0xffffffffa0091000 12K RW GLB x pte
0xffffffffa0091000-0xffffffffa0200000 1468K pte
0xffffffffa0200000-0xffffffffff000000 1518M pmd
---[ End Modules ]---
0xffffffffff000000-0xffffffffff400000 4M pmd
0xffffffffff400000-0xffffffffff513000 1100K pte
0xffffffffff513000-0xffffffffff514000 4K RW GLB NX pte
0xffffffffff514000-0xffffffffff5fb000 924K pte
0xffffffffff5fb000-0xffffffffff5fd000 8K RW PWT PCD GLB NX pte
0xffffffffff5fd000-0xffffffffff5ff000 8K pte
0xffffffffff5ff000-0xffffffffff600000 4K USR ro PWT PCD GLB x pte
0xffffffffff600000-0xffffffffff601000 4K USR ro GLB x pte
0xffffffffff601000-0xffffffffff800000 2044K pte
0xffffffffff800000-0x(null) 8M pmd
以下、気づいたこと。
/proc/vmallocinfoとつきあわせると、vmallocエリアの詳細がもっとわかるが、PCDが大量にあるのは、ACPIまわりのマッピングだから。あと、vmallocの仕様として、１ページ分余分に仮想空間を確保するので、いちいち4kずつ穴が空いていて見にくいね。
- 関連記事
-
- 海外さんが珍しく計算を間違っていた件について (2009/02/17)
- /sys/kernel/debug/kernel_page_tables (2009/02/16)
- Dreamcast VMU用ファイルシステム (2009/02/15)
会社にいこうと車にのるとフロントガラスに鳥フンがべったり。軽く凹む。
で、洗車にいくはめになったのだが、そういえば最近、会社の先輩がBlogで子供をのせて洗車にいったら子供がびびって面白かったとか書いてたのを思い出す。
んで、自分も洗車機やったっことないわー。とか思い出し初トライ。んー、たしかにビビるな、これは。うっかり窓を閉め忘れたらどうなるんだろう。とか考えてしまった。
洗車したあと、水を拭く場所がなくて、結局窓がよけい汚れてしまったので会社についてから拭いた。
で、洗車にいくはめになったのだが、そういえば最近、会社の先輩がBlogで子供をのせて洗車にいったら子供がびびって面白かったとか書いてたのを思い出す。
んで、自分も洗車機やったっことないわー。とか思い出し初トライ。んー、たしかにビビるな、これは。うっかり窓を閉め忘れたらどうなるんだろう。とか考えてしまった。
洗車したあと、水を拭く場所がなくて、結局窓がよけい汚れてしまったので会社についてから拭いた。
- 関連記事
-
- しまった (2009/03/09)
- 洗車機初トライ (2009/02/15)
- シアトルから絵はがきが届いた (2009/02/04)
が投稿されているな。
SEGAヲタの熱意ってほんと素晴らしいものがある。
http://en.wikipedia.org/wiki/VMU
を見るとVMUってのはDreamcast用のセーブデータ入れとくメモリーカードのようだ。
で、コードを見ると先頭のライセンス宣言部分にさりげなくPaul Mundtも共同署名されてる。
ちょwwww、Paulなにやってんの ：）
たしかに、shアーキテクチャーだけどさ。
SEGAヲタの熱意ってほんと素晴らしいものがある。
http://en.wikipedia.org/wiki/VMU
を見るとVMUってのはDreamcast用のセーブデータ入れとくメモリーカードのようだ。
Subject: [RFC][PATCH] filesystem: VMUFAT filesystem
From: Adrian McMenamin
The SEGA Dreamcast visual memory unit implements a file allocation table
based filesystem which is somewhat similar to FAT16. This filesystem
code implements that filesystem and I have used it to successfully
manage Dreamcast VMUs and VMU images mounted via loop.
You can read more about the filesystem here:
http://mc.pp.se/dc/vms/flashmem.html
I intend to fully document the filesystem and write an appropriate user
tool to create a drive image, but in the meantime here is an early cut
of the filesystem itself for comment.
(A version of this for the 2.4 kernel existed in the Dreamcast CVS on
Sourceforge but wasn't truly hardware independent).
で、コードを見ると先頭のライセンス宣言部分にさりげなくPaul Mundtも共同署名されてる。
ちょwwww、Paulなにやってんの ：）
たしかに、shアーキテクチャーだけどさ。
+/*
+ * inode operations for the VMU file system
+ *
+ * Copyright (C) 2002 - 2009 Adrian McMenamin
+ * Copyright (C) 2002 Paul Mundt
+ *
+ * Released under the terms of the GNU GPL v2.0.
+ */
- 関連記事
-
- /sys/kernel/debug/kernel_page_tables (2009/02/16)
- Dreamcast VMU用ファイルシステム (2009/02/15)
- Reiser4なんて誰も使ってないから-mmから落としましょう (2009/02/12)
ほうほう、from nowとfrom now onは違うのか
http://oshiete1.goo.ne.jp/qa142569.html
http://questionbox.jp.msn.com/qa613005.html
http://oshiete1.goo.ne.jp/qa142569.html
http://questionbox.jp.msn.com/qa613005.html
- 関連記事
-
- [英語] I'm afraid (2009/02/18)
- from now on (2009/02/13)
- What's up? (2009/02/12)
と提案したら各方面からお叱りを受けた。
そうは言っても誰も使ってないんだもん。
そうは言っても誰も使ってないんだもん。
- 関連記事
-
- Dreamcast VMU用ファイルシステム (2009/02/15)
- Reiser4なんて誰も使ってないから-mmから落としましょう (2009/02/12)
- 第10回 The Linux Foundation Japan Symposium (2009/02/10)
http://www.geocities.co.jp/Outdoors/9146/misc/wazzup.html
「どないでっか？」ぐらいの意味らしい。
「ぼちぼちでんな」はどう言えばいいのか・・・
「どないでっか？」ぐらいの意味らしい。
「ぼちぼちでんな」はどう言えばいいのか・・・
- 関連記事
-
- from now on (2009/02/13)
- What's up? (2009/02/12)
- [英語] A are currently busted due to B (2009/02/10)
A are currently busted due to B.
A はBのせいで壊れちゃっていて。
Mel Gormanに学んだ英語。
Bには自分のfeatureを壊したアホ・コミットを入れる。
例）
Hugepages are currently busted due to commit fc8744adc870a8d4366908221508bb113d8b72ee.
なお、ここでポイントなのは、名指しされているコミットがLinusパッチという所である ：）
A はBのせいで壊れちゃっていて。
Mel Gormanに学んだ英語。
Bには自分のfeatureを壊したアホ・コミットを入れる。
例）
Hugepages are currently busted due to commit fc8744adc870a8d4366908221508bb113d8b72ee.
なお、ここでポイントなのは、名指しされているコミットがLinusパッチという所である ：）
- 関連記事
-
- from now on (2009/02/13)
- What's up? (2009/02/12)
- [英語] A are currently busted due to B (2009/02/10)
の日程が公表されましたね。
http://jp.linuxfoundation.org/?q=node/163
今回は上司に売られたので発表者側。おかしいな、タスマニアで年功序列ルールにより、僕はありえません！！と力説してきたばかりなのだが。
http://jp.linuxfoundation.org/?q=node/163
今回は上司に売られたので発表者側。おかしいな、タスマニアで年功序列ルールにより、僕はありえません！！と力説してきたばかりなのだが。
- 関連記事
-
- Reiser4なんて誰も使ってないから-mmから落としましょう (2009/02/12)
- 第10回 The Linux Foundation Japan Symposium (2009/02/10)
- Rik がSplit LRU VMの感想をアップしてるな (2009/02/03)
おおお、綺麗だ。すばらしい！！
が、差出人が書いてない。
・・・どうしろとヽ(｀Д´)ﾉ
住所だけ分かっても意味ないっす
が、差出人が書いてない。
・・・どうしろとヽ(｀Д´)ﾉ
住所だけ分かっても意味ないっす
- 関連記事
-
- 洗車機初トライ (2009/02/15)
- シアトルから絵はがきが届いた (2009/02/04)
- 連載中止するかも (2009/02/03)
http://surriel.com/node/26
http://feedblog.org/2009/01/25/splitlru-patch-in-kernel-2628-must-have-for-mysql-and-innodb/
なんにせよ、たいしたトラブルもなくてよかった。よかった。
http://feedblog.org/2009/01/25/splitlru-patch-in-kernel-2628-must-have-for-mysql-and-innodb/
なんにせよ、たいしたトラブルもなくてよかった。よかった。
- 関連記事
-
- 第10回 The Linux Foundation Japan Symposium (2009/02/10)
- Rik がSplit LRU VMの感想をアップしてるな (2009/02/03)
- Japan Linux Symposium 神戸 (2009/02/03)
ジェットコースター的展開
某連載の編集者様から、不況だから原稿料下げますというメールが来た。むーん、そんなに不人気だったのか。しかも割合がでかい。
元々、執筆にはかなり時間を取られていたので時給閑散では最低賃金を大幅に下回っており、時給閑散では被害がすくないのだが、これって自己欺瞞だよな。とかとか
LKMLを全部読むというのはヨガの賢者も真っ青の苦行だったので、やめるなら今がチャンスでもある。
現在、関係者と鋭意協議中。
某連載の編集者様から、不況だから原稿料下げますというメールが来た。むーん、そんなに不人気だったのか。しかも割合がでかい。
元々、執筆にはかなり時間を取られていたので時給閑散では最低賃金を大幅に下回っており、時給閑散では被害がすくないのだが、これって自己欺瞞だよな。とかとか
LKMLを全部読むというのはヨガの賢者も真っ青の苦行だったので、やめるなら今がチャンスでもある。
現在、関係者と鋭意協議中。
- 関連記事
-
- シアトルから絵はがきが届いた (2009/02/04)
- 連載中止するかも (2009/02/03)
- LinusがKDEからGNOMEに環境変えたらしい (2009/01/26)
会社で聞いた面白い話。
先日告知が行われた、今年のJapan Linux Symposiumについて本家Linux Foundationでも告知がされているが、開催地アキバのはずなのに写真は「どうみても神戸です本当にありがとうございました」状態だという・・・・
URLと記念スクリーンショットをはっときます。
先日告知が行われた、今年のJapan Linux Symposiumについて本家Linux Foundationでも告知がされているが、開催地アキバのはずなのに写真は「どうみても神戸です本当にありがとうございました」状態だという・・・・
URLと記念スクリーンショットをはっときます。
- 関連記事
-
- Rik がSplit LRU VMの感想をアップしてるな (2009/02/03)
- Japan Linux Symposium 神戸 (2009/02/03)
- kernel watch １月号 (2009/02/01)
公開されました。
http://www.atmarkit.co.jp/flinux/rensai/watch2009/watch01a.html
手違いで、リンクが切れているようなので、編集者さんと相談します。
前回掲載が今月頭までずれ込んだ事と、今回オーストラリア出発前に原稿をあげる必要があったので１週間しかなかったわりには、よい記事になったと思います。
http://www.atmarkit.co.jp/flinux/rensai/watch2009/watch01a.html
手違いで、リンクが切れているようなので、編集者さんと相談します。
前回掲載が今月頭までずれ込んだ事と、今回オーストラリア出発前に原稿をあげる必要があったので１週間しかなかったわりには、よい記事になったと思います。
- 関連記事
-
- Japan Linux Symposium 神戸 (2009/02/03)
- kernel watch １月号 (2009/02/01)
- 犯罪者っすか (2009/01/29)