以下のようなエラーが発生して起動しなくなった。
- 関連記事
-
- なんか業務効率が悪いと思ったら (2008/08/01)
- firefoxの自動アップデートが失敗した (2008/07/29)
- たまに勘違いしている人がいますが (2008/07/24)
よく考えればどうせ恥をさらすだけなのだから、申し込みをやめておけばよかった。
反省
- 関連記事
-
- mlock の戻り値 (2008/08/05)
- うむむ (2008/07/29)
- ext4は遅い ３杯目 (2008/07/26)
From: Jan Blunck
To: [email protected]
Subject: kernel build time
After Andreas talk yesterday I did some tests on my T61. This is not really a
perfect benchmark setup but Andreas said I should send the data anyway.
make clean (ext3)
real 0m3.073s
user 0m1.324s
sys 0m1.444s
make -j 4 (ext3)
real 6m37.377s
user 10m58.081s
sys 1m38.890s
make clean (ext4)
real 0m6.443s
user 0m1.712s
sys 0m1.824s
make -j 4 (ext4)
real 6m42.694s
user 10m59.593s
sys 1m36.994s
Filesystem features: has_journal ext_attr resize_inode dir_index filetype
needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg
dir_nlink extra_isize
Filesystem flags: signed_directory_hash test_filesystem
That is with the patch queue from
http://www.kernel.org/pub/linux/kernel/people/tytso/ext4-patches/2.6.26-ext4-1
on top of 2.6.26. Both ext3 and ext4dev are running on logical volumes (no
barrier support). I used the latest e2fsprogs available.
HTH,
Jan
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
- 関連記事
-
- うむむ (2008/07/29)
- ext4は遅い ３杯目 (2008/07/26)
- Xでの電力消費 (2008/07/21)
- 関連記事
-
- firefoxの自動アップデートが失敗した (2008/07/29)
- たまに勘違いしている人がいますが (2008/07/24)
- ビアンカとフローラ (2008/07/24)
以下に理由を列挙してみる
・天空の盾を手に入れるにはフローラしかない。
ビアンカを選んでも結婚式はやってあげると言われているが、盾をあげるとは一言も。。
目的を思い出せ、自分
・フローラ嫁、ビアンカ愛人ルートは妄想の範囲内だが、逆はないだろう。
・てゆーか、話を盛り上げる為には、小説とかなら、フローラと結婚しておいて
自分の娘が8歳になったときに、ビアンカとの思い出が蘇ってきて・・・
というのが定番ではないか。
だがしかし、フローラとの子供が倉が気に入らないのであった。
なんの話かは秘密
- 関連記事
-
- たまに勘違いしている人がいますが (2008/07/24)
- ビアンカとフローラ (2008/07/24)
- こんな夜中に (2008/07/24)
- 関連記事
-
- ビアンカとフローラ (2008/07/24)
- こんな夜中に (2008/07/24)
- ビジネスクラスとれた (2008/07/18)
マウス動かすだけで狂ったようにgettimeofday()が発行されてクソ遅いし、電力のむだだーー
とかいう話があったと思うんだけど、今どうなってるか誰か知らない？
- 関連記事
-
- ext4は遅い ３杯目 (2008/07/26)
- Xでの電力消費 (2008/07/21)
- munlock rework (2008/07/21)
まさに光速。
ふつう、get_user_pages()なんて頻出コードをいじるときはもっと議論がなされるものだけど、今回はバグフィックス扱いでakpm特権でマージしたみたいだね。
そして、reclaim throttleは今回もマージされなかったのでした（；＿；
- 関連記事
-
- Xでの電力消費 (2008/07/21)
- munlock rework (2008/07/21)
- 2.6.26の全CPUのバックトレースを表示する機能について補足 (2008/07/18)
食べ物はインターバルが長いと食べ方を忘れるな。常識的に考えて
- 関連記事
-
- ニューテクノロジーは伊達じゃない (2008/08/22)
- ああ、んん、溶けちゃうよー (2008/07/21)
- ピカチュリン (2008/07/21)
目で受けた光の刺激を、電気信号で脳に伝える際に重要な働きをするタンパク質を、大阪バイオサイエンス研究所の古川貴久研究部長（神経発生学）らのチームがマウスを使った実験で発見。電気を操るネズミに似た人気アニメキャラクターにちなみ「ピカチュリン」と命名し、２１日、米科学誌ネイチャー・ニューロサイエンス電子版に発表した。
ヒトなどのほ乳類の目では、光の刺激が網膜の視細胞で電気信号に変わり、双極細胞を通過して視神経から脳へ伝達される。現在、目の疾患に対してはｉＰＳ細胞（人工多能性幹細胞）などで視細胞を作ることはできても、神経伝達回路であるシナプスの形成過程が解明できていないことから、臨床応用は現実的でないとされてきた。
古川部長らは、マウスの実験で視細胞と双極細胞の間をつなぐ視神経の周りに特異的に発現しているタンパク質を発見。光を発して電気を操る人気アニメキャラクター「ピカチュウ」をもじって「ピカチュリン」と名付けた。古川部長は「網膜の神経回路のメカニズムを明らかにする大きな一歩。将来的にもｉＰＳ細胞で視細胞を作り出す再生医療に応用できる」と話した。
ソニック・ヘッジホッグとかポケモン遺伝子とかも教科書にのってるらしいしな。
ほんとナマモノ業界の著作権無視は地獄だぜーー
./ ;ヽ
l ＿,,,,,,,,＿,;;;;i ＜いいぞ ベイべー！
l l''|~___;;､_y__ lﾐ;l 逃げる奴はベトコンだ！！
ﾞl;| | `'",;_,i`'"|;i | 逃げない奴はよく訓練されたベトコンだ！！
,r''i ヽ, '~rーj`c=/
,／ ヽ ヽ`ｰ"/:: `ヽ
/ ﾞヽ ￣､::::: ﾞl, ホント 戦場は地獄だぜ！ フゥハハハーハァー
|;/"⌒ヽ, ＼ ヽ: _l＿ ri ri
l l ヽr‐─ヽ＿|_⊂////;`ゞ--―─-r| | / |
ﾞlﾞl, l,|｀ﾞﾞﾞ''―ll＿__l,,l,|,iﾉ二二二二│｀""""""""""""|二;;二二;;二二二i≡二三三l
| ヽ ヽ _|＿ ＿ "l￣￣￣￣￣￣ |二;;二二;;二='''''''''''￣ﾉ
/"ヽ 'j＿／ヽヽ,￣ ,,,/"''''''''''''⊃r‐l'二二二T￣￣￣ ［iﾞ''''''''''''''''"ﾞﾞﾞ￣`"
／ ヽ ー──''''''""(;;) ｀ﾞ,j" | | |
- 関連記事
-
- ああ、んん、溶けちゃうよー (2008/07/21)
- ピカチュリン (2008/07/21)
- 日本はじまったなー (2008/07/14)
ほほー
- 関連記事
-
- こんな夜中に (2008/07/24)
- ビジネスクラスとれた (2008/07/18)
- 虫がわいた (2008/07/15)
が2.6.26の新機能として上がっているが、これがどういうものかというと、Magic SYSRQにl を打ち込むと全CPUの処理箇所が取れるというもの。
以下、使用例
# ./hackbench 10 process 10000 &
# echo l > /proc/sysrq-trigger
SysRq : Show backtrace of all active CPUs
Call Trace:
[] show_stack+0x80/0xa0
sp=e00000005ab8f8a0 bsp=e00000005ab811f0
[] showacpu+0xa0/0xe0
sp=e00000005ab8fa70 bsp=e00000005ab811d0
[] handle_IPI+0x210/0x3a0
sp=e00000005ab8fa70 bsp=e00000005ab81160
[] handle_IRQ_event+0x80/0x120
sp=e00000005ab8fa70 bsp=e00000005ab81128
[] __do_IRQ+0x140/0x420
sp=e00000005ab8fa70 bsp=e00000005ab810c8
[] ia64_handle_irq+0x3f0/0x420
sp=e00000005ab8fa70 bsp=e00000005ab81050
[] ia64_native_leave_kernel+0x0/0x270
sp=e00000005ab8fa70 bsp=e00000005ab81050
[] sock_alloc_send_skb+0x470/0x560
sp=e00000005ab8fc40 bsp=e00000005ab80fb8
[] unix_stream_sendmsg+0x3b0/0x6a0
sp=e00000005ab8fc70 bsp=e00000005ab80f18
[] sock_aio_write+0x260/0x2a0
sp=e00000005ab8fca0 bsp=e00000005ab80ed8
[] do_sync_write+0x170/0x260
sp=e00000005ab8fd20 bsp=e00000005ab80e88
[] vfs_write+0x310/0x320
sp=e00000005ab8fe20 bsp=e00000005ab80e38
[] sys_write+0x70/0xe0
sp=e00000005ab8fe20 bsp=e00000005ab80db8
[] ia64_ret_from_syscall+0x0/0x20
sp=e00000005ab8fe30 bsp=e00000005ab80db8
[] __kernel_syscall_via_break+0x0/0x20
sp=e00000005ab90000 bsp=e00000005ab80db8
Call Trace:
[] show_stack+0x80/0xa0
sp=e0000000670ef8b0 bsp=e0000000670e1258
[] showacpu+0xa0/0xe0
sp=e0000000670efa80 bsp=e0000000670e1238
[] handle_IPI+0x210/0x3a0
sp=e0000000670efa80 bsp=e0000000670e11c0
[] handle_IRQ_event+0x80/0x120
sp=e0000000670efa80 bsp=e0000000670e1188
[] __do_IRQ+0x140/0x420
sp=e0000000670efa80 bsp=e0000000670e1128
[] ia64_handle_irq+0x3f0/0x420
sp=e0000000670efa80 bsp=e0000000670e10b0
[] ia64_native_leave_kernel+0x0/0x270
sp=e0000000670efa80 bsp=e0000000670e10b0
[] unix_write_space+0x50/0x140
sp=e0000000670efc50 bsp=e0000000670e1070
[] sock_wfree+0x120/0x180
sp=e0000000670efc50 bsp=e0000000670e1048
[] skb_release_all+0x100/0x1a0
sp=e0000000670efc50 bsp=e0000000670e1020
[] __kfree_skb+0x20/0x1a0
sp=e0000000670efc50 bsp=e0000000670e1000
[] kfree_skb+0x60/0xc0
sp=e0000000670efc50 bsp=e0000000670e0fd8
[] unix_stream_recvmsg+0x360/0xa60
sp=e0000000670efc50 bsp=e0000000670e0f08
[] sock_aio_read+0x260/0x2a0
sp=e0000000670efca0 bsp=e0000000670e0ec8
[] do_sync_read+0x170/0x260
sp=e0000000670efd20 bsp=e0000000670e0e78
[] vfs_read+0x310/0x320
sp=e0000000670efe20 bsp=e0000000670e0e28
[] sys_read+0x70/0xe0
sp=e0000000670efe20 bsp=e0000000670e0da8
[] ia64_ret_from_syscall+0x0/0x20
sp=e0000000670efe30 bsp=e0000000670e0da8
[] __kernel_syscall_via_break+0x0/0x20
sp=e0000000670f0000 bsp=e0000000670e0da8
Call Trace:
[] show_stack+0x80/0xa0
sp=e00000005f8efa80 bsp=e00000005f8e1048
[] showacpu+0xa0/0xe0
sp=e00000005f8efc50 bsp=e00000005f8e1028
[] handle_IPI+0x210/0x3a0
sp=e00000005f8efc50 bsp=e00000005f8e0fb0
[] handle_IRQ_event+0x80/0x120
sp=e00000005f8efc50 bsp=e00000005f8e0f78
[] __do_IRQ+0x140/0x420
sp=e00000005f8efc50 bsp=e00000005f8e0f18
[] ia64_handle_irq+0x3f0/0x420
sp=e00000005f8efc50 bsp=e00000005f8e0ea0
[] ia64_native_leave_kernel+0x0/0x270
sp=e00000005f8efc50 bsp=e00000005f8e0ea0
[] inotify_inode_queue_event+0x0/0x200
sp=e00000005f8efe20 bsp=e00000005f8e0e78
[] vfs_read+0x270/0x320
sp=e00000005f8efe20 bsp=e00000005f8e0e28
[] sys_read+0x70/0xe0
sp=e00000005f8efe20 bsp=e00000005f8e0da8
[] ia64_ret_from_syscall+0x0/0x20
sp=e00000005f8efe30 bsp=e00000005f8e0da8
[] __kernel_syscall_via_break+0x0/0x20
sp=e00000005f8f0000 bsp=e00000005f8e0da8
Call Trace:
[] show_stack+0x80/0xa0
sp=e0000000500afa80 bsp=e0000000500a1080
[] showacpu+0xa0/0xe0
sp=e0000000500afc50 bsp=e0000000500a1060
[] handle_IPI+0x210/0x3a0
sp=e0000000500afc50 bsp=e0000000500a0fe8
[] handle_IRQ_event+0x80/0x120
sp=e0000000500afc50 bsp=e0000000500a0fb0
[] __do_IRQ+0x140/0x420
sp=e0000000500afc50 bsp=e0000000500a0f50
[] ia64_handle_irq+0x3f0/0x420
sp=e0000000500afc50 bsp=e0000000500a0ed8
[] ia64_native_leave_kernel+0x0/0x270
sp=e0000000500afc50 bsp=e0000000500a0ed8
[] rw_verify_area+0xf0/0x1a0
sp=e0000000500afe20 bsp=e0000000500a0e78
[] vfs_read+0x120/0x320
sp=e0000000500afe20 bsp=e0000000500a0e28
[] sys_read+0x70/0xe0
sp=e0000000500afe20 bsp=e0000000500a0da8
[] ia64_ret_from_syscall+0x0/0x20
sp=e0000000500afe30 bsp=e0000000500a0da8
[] __kernel_syscall_via_break+0x0/0x20
sp=e0000000500b0000 bsp=e0000000500a0da8
Call Trace:
[] show_stack+0x80/0xa0
sp=e00000006ceefa80 bsp=e00000006cee0fe8
[] showacpu+0xa0/0xe0
sp=e00000006ceefc50 bsp=e00000006cee0fc8
[] handle_IPI+0x210/0x3a0
sp=e00000006ceefc50 bsp=e00000006cee0f58
[] handle_IRQ_event+0x80/0x120
sp=e00000006ceefc50 bsp=e00000006cee0f20
[] __do_IRQ+0x140/0x420
sp=e00000006ceefc50 bsp=e00000006cee0ec0
[] ia64_handle_irq+0x3f0/0x420
sp=e00000006ceefc50 bsp=e00000006cee0e48
[] ia64_native_leave_kernel+0x0/0x270
sp=e00000006ceefc50 bsp=e00000006cee0e48
[] fget_light+0x30/0x1a0
sp=e00000006ceefe20 bsp=e00000006cee0e28
[] sys_read+0x30/0xe0
sp=e00000006ceefe20 bsp=e00000006cee0da8
[] ia64_ret_from_syscall+0x0/0x20
sp=e00000006ceefe30 bsp=e00000006cee0da8
[] __kernel_syscall_via_break+0x0/0x20
sp=e00000006cef0000 bsp=e00000006cee0da8
Call Trace:
[] show_stack+0x80/0xa0
sp=e000000065dafa80 bsp=e000000065da1080
[] showacpu+0xa0/0xe0
sp=e000000065dafc50 bsp=e000000065da1060
[] handle_IPI+0x210/0x3a0
sp=e000000065dafc50 bsp=e000000065da0fe8
[] handle_IRQ_event+0x80/0x120
sp=e000000065dafc50 bsp=e000000065da0fb0
[] __do_IRQ+0x140/0x420
sp=e000000065dafc50 bsp=e000000065da0f50
[] ia64_handle_irq+0x3f0/0x420
sp=e000000065dafc50 bsp=e000000065da0ed8
[] ia64_native_leave_kernel+0x0/0x270
sp=e000000065dafc50 bsp=e000000065da0ed8
[] rw_verify_area+0x100/0x1a0
sp=e000000065dafe20 bsp=e000000065da0e78
[] vfs_read+0x120/0x320
sp=e000000065dafe20 bsp=e000000065da0e28
[] sys_read+0x70/0xe0
sp=e000000065dafe20 bsp=e000000065da0da8
[] ia64_ret_from_syscall+0x0/0x20
sp=e000000065dafe30 bsp=e000000065da0da8
[] __kernel_syscall_via_break+0x0/0x20
sp=e000000065db0000 bsp=e000000065da0da8
Call Trace:
[] show_stack+0x80/0xa0
sp=e000000069befa90 bsp=e000000069be0f70
[] showacpu+0xa0/0xe0
sp=e000000069befc60 bsp=e000000069be0f50
[] handle_IPI+0x210/0x3a0
sp=e000000069befc60 bsp=e000000069be0ee0
[] handle_IRQ_event+0x80/0x120
sp=e000000069befc60 bsp=e000000069be0ea8
[] __do_IRQ+0x140/0x420
sp=e000000069befc60 bsp=e000000069be0e48
[] ia64_handle_irq+0x3f0/0x420
sp=e000000069befc60 bsp=e000000069be0dc8
[] ia64_native_leave_kernel+0x0/0x270
sp=e000000069befc60 bsp=e000000069be0dc8
[] sys_read+0x0/0xe0
sp=e000000069befe30 bsp=e000000069be0da8
[] ia64_ret_from_syscall+0x0/0x20
sp=e000000069befe30 bsp=e000000069be0da8
[] __kernel_syscall_via_break+0x0/0x20
sp=e000000069bf0000 bsp=e000000069be0da8
- 関連記事
-
- munlock rework (2008/07/21)
- 2.6.26の全CPUのバックトレースを表示する機能について補足 (2008/07/18)
- [ANNOUNCE] The Linux Test Project has been Released for JUNE 2008 (2008/07/17)
LTPの新版がリリース。今回のハイライトは
* Addition of timerfd(), utimensat(), gettid() & io_cancel() tests,
* Addition of CPU & MEMORY HOTPLUG tests,
* Addition of Process Event Connector tests,
* Addition of Hackbench test,
* RT tests fix for START_LATENCY,
* FS_BIND fix for ia64 & for kernels below 2.6.15,
* SE-Linux fix to build against the latest refpolicy headers,
* Concurrency Fixes for some tests.
でも、メモリーホットプラグのテストはダメダメらしい。
- 関連記事
-
- 2.6.26の全CPUのバックトレースを表示する機能について補足 (2008/07/18)
- [ANNOUNCE] The Linux Test Project has been Released for JUNE 2008 (2008/07/17)
- sched_mc_power_savings (2008/07/17)
Vaidyanathan Srinivasan がスケジューラに手をいれて
echo 1 > /sys/devices/system/cpu/sched_mc_power_savings
ってやったら、なるべく処理を少ない数のCPUで行うようにしようと提案。目的は省電力機能の追加らしい。
で、インターフェースがどうのと、うだうだ議論したあと、nice, ioniceについてpowerniceを作ろうという斜め上の結論に。
ええ、これを使うとプロセスは省電力モードで動くんです。
もちろん、実装はまだない
- 関連記事
-
- [ANNOUNCE] The Linux Test Project has been Released for JUNE 2008 (2008/07/17)
- sched_mc_power_savings (2008/07/17)
- printkの非互換にたいする指摘 (2008/07/17)
linux-2.6.26のリリース直前でLinusがprintkに構文拡張を入れました（そうです。Linusが書いたコードはマージウィンドとか関係なく常にいきなりmainlineにマージされるのです）
具体的には
%pS: ポインタのシンボル名を表示（データ）
%pF: ポインタのシンボル名を表示（関数）
の２つ。ああ、IA64とかでは関数ポインタの扱いが特殊だから%pSだけに出来ないんだわ。
最初は%Sにするつもりだったのだが、誰かが、それってgccの__attribute__((format(printf, ..)))が警告だすやんけ。という話があって、二文字フォーマットしかないねという結論に。
んで、それに対して、Matthew Wilcoxがつけたコメントが
printk("Function %pSucks\n", sys_open);
が非互換になるよねー。まあもっともそんなコードがカーネルの中にあるとも思えないけども（＾＾）
そうです。LKMLは英語圏の２ｃｈなので、どんな議論でもSuckとかCrap言わないと議論が進まないのです！
- 関連記事
-
- sched_mc_power_savings (2008/07/17)
- printkの非互換にたいする指摘 (2008/07/17)
- あなたが何処の星の生まれかは知らないが (2008/07/17)
全然技術的な話が出てこないので、はっきり言って苦行。
でも以下のメールはﾜﾗﾀ
> It almost never happens that you have kernel versions which _need_
> different firmware installed. In almost all cases, the older driver will
> continue to work just fine with the newer firmware (and its bug-fixes).
I'm not sure which planet you're from, but it's one without ipw2200
chips in it. And in any case, the file names change.
全否定された David Woodhouse 涙目。
てゆーか、LKMLってほんと会話のノリが２ｃｈだよな
- 関連記事
-
- printkの非互換にたいする指摘 (2008/07/17)
- あなたが何処の星の生まれかは知らないが (2008/07/17)
- GPL v4 (2008/07/17)
From: "Morton Harrow"
To: [email protected]
Date: Thu, 17 Jul 2008 02:09:53 +0800
Subject: GPL version 4
Dear gentlemen (and included list-members),
Let me first introduce myself. My name is Morton Harrow, senior GNU/Linux consultant in the London metropolitan area. I have been around in the Open Source world since the early beginning. I am very happy with the spirit and efforts of the Free Software Foundation (FSF).
As the name mentions “free”, one would think this organisation embraces real freedom. I can't help but feel that the FSF has made a mistake with the release of the third version of the GPL (GPLv3). This license restricts the freedom and usage of open source software for governments, companies and end-users alike.
Linking from other software which is not regarded by the FSF as free software, is not allowed by this license. I can't help but wonder if this is the freedom the FSF intensions. Real free should be that users are allowed link any software against GPL licensed software, without restrictions. But the current “freedom” restricts the spirit of Richard M. Stallman's original vision on a free world.
We propose to release as soon as possible, version 4 of the General Public License.
The GPL version 4 will accept every other license, accepted by the Open Source Initiative as open source. Corporate usage of GPL released software should be possible without restrictions. Linking from closed source software to GPLv4 software and libraries will be permitted. GPLv4 software can be shipped in (commercial) closed source software. Only this and the original authors need to be mentioned. Also, I believe the copyright of the FSF software should be transferred to the United Nations. As “human knowledge belongs to the world.”
Our planned release date of GPLv4 is 15th September 2008. The first software to be released under the terms of this new license, will be a continuation of the stalled ReiserFS project. As the FSF headers allow software to be released under the terms of the GPLv2 or higher, we will prepare automatic relicensing of GPLv2 and GPLv3 software to the GPLv4.
If you have any questions or comments, please feel free to contact me.
With kind regards,
Morton Harrow
=
--
Powered by Outblaze
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
すかさずAdrian Bunk が
ROTFL
I've double-checked my calendar - today isn't April 1st.
Please don't feed the troll.
うわ。まったく相手にされてねーーー
- 関連記事
-
- あなたが何処の星の生まれかは知らないが (2008/07/17)
- GPL v4 (2008/07/17)
- tracepoint (2008/07/16)
と言っている。
真にもっともだがぶっちゃけメンドイからだと思う。
あと、mmapを使ったused onceページは扱いが難しいんじゃよー
mmapでタッチした瞬間にaccess bitが立ってしまうので、普通はそこで即捨て候補からはずれてしまうからな。
今うず高くつみあがっている残作業が消えたら、なんか考えてもいいな
mm/madvise.c and madvise(2) say:
* MADV_SEQUENTIAL - pages in the given range will probably be accessed
* once, so they can be aggressively read ahead, and
* can be freed soon after they are accessed.
But as the sample program at the end of this post shows, and as I
understand the code in mm/filemap.c, MADV_SEQUENTIAL will only increase
the amount of read ahead for the specified page range, but will not
influence the rate at which the pages just read will be freed from
memory.
Running the sample program on a large file, say 4GB on a machine with
3GB of RAM, the resident size of the program will grow enough to evict
pretty much everything else. (on 2.6.25.9-40.fc8)
Right before the program below is done reading the 4GB file:
7f6c3e654000-7f6d3e654000 r--s 00000000 fd:02 98125 /tmp/bigfile
Size: 4194304 kB
Rss: 2472220 kB
Pss: 2472220 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 2472220 kB
Private_Dirty: 0 kB
Referenced: 718748 kB
I'm well aware that the kernel is free to ignore the advice given
through madvise(2) (fadvise(2) seems to behave similarly, btw), so I'm
certainly not claiming this is a bug. However, I was wondering what was
the rationale behind it, and whether the manpages should be updated to
be more accurate.
There is a very straightforward workaround: MADV_DONTNEED on the range
just read, every so often, will be very effective at controlling the
resident size of the mapping. (mm/madvise.c:madvise_dontneed() calls
zap_page_range())
Thanks.
---
# dd if=/dev/zero of=/tmp/bigfile bs=1024 count=$((4*1024*1024))
# gcc test.c
# Run:
file=/tmp/bigfile; ./a.out $file & pid=$! ; while true; do cat /proc/$pid/smaps | grep -A 8 $file; sleep 1; done
# cat test.c
#include
#include
#include
#include
#include
#include
#include
#include
int main(int argc, char **argv)
{
if (argc != 2)
return -EINVAL;
char *fn = argv[1];
int fd = open(fn, O_RDONLY);
if (fd < 0)
return -errno;
struct stat st;
int ret = fstat(fd, &st);
if (ret)
return -errno;
unsigned char *map = mmap(0, st.st_size, PROT_READ, MAP_SHARED, fd, 0);
if (map == MAP_FAILED)
return -errno;
ret = madvise(map, st.st_size, MADV_SEQUENTIAL);
if (ret) {
fprintf(stderr, "madvise failed\n");
return -errno;
}
const int pagesize = sysconf(_SC_PAGESIZE);
unsigned char dummy = 0;
off_t i;
for (i = 0; i < st.st_size; i += pagesize) {
dummy += map[i];
}
munmap(map, st.st_size);
close(fd);
return dummy;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- 関連記事
-
- GPL v4 (2008/07/17)
- tracepoint (2008/07/16)
- hugepages_treat_as_movable (2008/07/15)
しかし、これはいつ使うのか微妙なパラメタだな
- 関連記事
-
- tracepoint (2008/07/16)
- hugepages_treat_as_movable (2008/07/15)
- パッチキューのかさが上がった (2008/07/15)
もう、パッチ名みてもどのパッチか分からんよ(´・ω・｀)
- 関連記事
-
- hugepages_treat_as_movable (2008/07/15)
- パッチキューのかさが上がった (2008/07/15)
- ぐは (2008/07/15)
うっとおしくて仕方がないが駆除の仕方が分からない。
アーー、腹立つ
- 関連記事
-
- ビジネスクラスとれた (2008/07/18)
- 虫がわいた (2008/07/15)
- パスポート (2008/07/03)
てゆーか、IA64なんてマイナーなハードではピクリともコンパイルできないモジュールが多すぎです
明日からは普通にやる。たぶん
- 関連記事
-
- パッチキューのかさが上がった (2008/07/15)
- ぐは (2008/07/15)
- Removal of FUTEX_FD (2008/07/14)
- 関連記事
-
- ぐは (2008/07/15)
- Removal of FUTEX_FD (2008/07/14)
- [RFC] Improved versioned pointer algorithms (2008/07/14)
でも、正直btrfsはこういう性能改善を議論するレベルまでいってないと思うんだ。
Greetings, filesystem algorithm fans.
The recent, detailed description of the versioned pointer method for
volume versioning is here:
http://linux.derkeiler.com/Mailing-Lists/Kernel/2008-07/msg02663.html
I apologize humbly for the typo in the first sentence. Today's revision
of the proof of concept code is cleaned up to remove some redundant
logic from the exception delete and origin write algorithms, and has
a number of small improvements. The fuzzing test has run to 20 million
iterations without problems. Some of the more complex logic has become
simple to the point where it can possibly be seen to be correct in
addition to merely running correctly.
The current efficiency scores for the six basic operations are:
Origin write: O(exceptions)
Snapshot write: O(versions)
Snapshot delete: O(versions)
Snapshot read: O(exceptions)
Snapshot of origin: O(versions)
Snapshot of snapshot: O(versions)
This is mainly about CPU time rather than filesystem efficiency. The
real time performance will be dominated by disk operations as usual.
Snapshot write is a frequent operation and snapshot delete is performed
on large amounts of metadata at a time, so it would be nice to improve
their performance to be independent of the number of versions created.
O(exceptions) orphan test
-------------------------
It is only the orphan searches that increase snapshot write and
snapshot delete running times from O(exceptions) to O(versions),
otherwise the main algorithm is already O(exceptions).
The orphan test is used in snapshot write and exception delete to
identify any new orphans created as a result of a write that creates an
exclusive exception for the only heir of the ghost exception, or a
delete that removes the only heir and does not promote a new heir.
The current method of determining whether a ghost exception is an
orphan is to recurse through the subtree below the ghost until a visible
version is found that inherits the exception. This traversal runs in
O(versions) time.
To perform this test in O(exceptions) time, we proceed as follows:
First, identify a subtree of the version tree consisting only of ghost
versions in interior nodes and visible versions at terminal nodes,
descending from the ghost ancestor of the victim version nearest the
root and having no visible versions or present exceptions between itself
and the victim. Call each interior node of that subtree a "nexus",
which must have more than one child because it is a ghost. This step
is done once, prior to a full-tree version delete pass.
The interesting question is whether a ghost exception is inherited
by any visible version that does not appear in the same exception list.
If not, then the ghost exception is an orphan that must be deleted.
This can be computed efficiently using a bottom up approach with a
single pass through the exception list. At each nexus keep a count of
the children of the nexus that are known not to inherit from that
nexus. Call that the blocked count. Set the blocked counts to zero
and:
For each exception in the exception list:
If the version labeled by the exception is in the ghost
tree then increment the blocked count of the nexus parent
If the blocked count is now equal to the number of children
of the nexus then repeat from the preceding step
At completion, if the blocked count of the ghost ancestor is equal to
its child count then the ghost exception is an orphan, otherwise not.
Example
-------
Below, ghost versions are marked with ~ and members of the ghost tree
are marked with *.
.
`-- A
|-- B
`-- *C~
|-- *D
|-- E <== victim to be deleted
`-- *F~
|-- *G
`-- *H
|-- I
`-- J
Version C is the single ghost ancestor (there may be more than one) that
may contain an orphan exception. D does not belong to the ghost tree
because it is to be deleted and has already been removed from the
version tree when the ghost tree is constructed. The interior nexus
nodes are C and F while D, G and H are terminal, user visible nodes of
the ghost tree.
Overlaying the exception list [I, p1] [G, p2] [C, p3] [D, p4] on the
example tree:
.
`-- A
|-- B
`-- *C~ [p3]
|-- *D [p4]
|-- E <== deleted victim
`-- *F~
|-- *G [p2]
`-- *H
|-- I [p1]
`-- J
When exception [I, p1] is found it is ignored because it is not a member
of the ghost tree. H has no exception, so [G, p2] cannot cause the
algorithm to iterate past node F. Processing [D, p4] will raise the
nexus count at C to one, but C has two children after ignoring E (which
is deleted by this time) so [C, p3] is not an orphan. Examining the
tree shows that visible version H continues to inherit the ghost
exception at C, which could now be relabeled to H if desired, but since
it will be detected and deleted in the fullness of time anyway there
is little point in doing that extra work here.
If any of versions F, H or J had an exception then [C, p3] would be an
orphan.
O(log(exceptions)) snapshot lookup
----------------------------------
An O(log(exceptions)) snapshot lookup is known to exist and is left as
an exercise for the interested reader.
Updated versioned pointers fuzztest attached
--------------------------------------------
c99 fuzzversion.c && ./a.out
Request for comment from Btrfs and ZFS developers
-------------------------------------------------
I am considering the wisdom of developing a filesystem based on
versioned pointers. The prospect of per-file and per-directory
versioning seems attractive, as does the elegant formulation of
snapshots-of-snapshots and the compact metadata. I suspect that less
updating of metadata will be required for writes versus either Btrfs or
ZFS. Mind you, there is no working filesystem code at the moment, only
ddsnap the snapshotting block device and the attached proof of concept
of versioned pointers, so some of this is speculation.
I described earlier how versioned pointers will be extended to versioned
extents but have not yet tried it. This would be necessary in order to
operate in the same ballpark of efficiency as ZFS or Btrfs.
Versioned pointers have some advantages over versioning methods used in
ZFS and Btrfs, and also some potential drawbacks:
Advantages versus ZFS and Btrfs:
* No per-write recursive copy on write of metadata blocks. Creating a
new copy of a data block normally only requires inserting a new
versioned pointer to a btree leaf block. Such inserts can be logged
logically and added to the btree in large batches, which can be done
atomically using standard methods (physical journal, log or copy on
write).
Advantages versus Btrfs:
* No reference count updates, which must be be durable and atomic,
surely a painful overhead. Instead, it can be determined entirely
from the exception list whether a given block is referenced, so
only exception lists need to be updated, and only by adding,
removing, or in rare cases, relabeling physical pointers.
Advantages versus ZFS:
* No need to maintain a dead list. This information can be entirely
determined from the combination of the versioned pointers and the
version tree.
* It would seem that ZFS is deeply wedded to the concept of a single,
linear chain of snapshots. No snapshots of snapshots, apparently.
http://blogs.sun.com/ahrens/entry/is_it_magic
Drawbacks of versioned pointers:
* All version info stored together for any given logical address.
This will require reading more metadata blocks as the number of
versions increases, and put more pressure on cache. How to fix: with
extents, metadata is tiny compared to data, even if expanded by a
large factor, so it may not matter. If it does, an in-memory version
of accessed btree nodes for a particular snapshot can be cached and
saved persistently to disk so that the full version btree only
rarely needs to be accessed.
* Delete is a full tree pass over the metadata. But this can be done
in the background for multiple deleted versions per pass. Also can
keep a persistent cache per version of which logical address ranges
have exceptions for a given version to limit the search.
* Limited number of versions. This can be overcome mindlessly by
extending the size of a physical pointer, or more elegantly by
keeping a per-leaf "wide" translation table of versions referenced
by the leaf, or both depending on which representation is smaller for
a particular leaf.
- 関連記事
-
- Removal of FUTEX_FD (2008/07/14)
- [RFC] Improved versioned pointer algorithms (2008/07/14)
- linux 2.6.26 (2008/07/14)
「夏場に男子が胸元をはだけているとムラムラする。
生徒会はもっと服装チェックを厳しくしてほしい。」
「男子の間で流行っている陰毛の毟りあいを何とかして欲しい。
掃除の時間に床中に縮れ毛が散らばってるのが非常に不快です。」
「シャワー室周辺を全裸で歩き回る男子を何とかして欲しい。
もしくはそれを覗き見に集まる女子達を何とかして欲しい。」
「男子の二の腕を見ているとドキドキして授業に集中できないので
男子は夏場でも長袖にしてほしい。」
「男子同士のじゃれ合いを見ていると妄想がかき立てられるので
不純同性交友も禁止してほしい。」
「男子更衣室・男子シャワールームの窓を磨りガラスから透明なものにしてほしい。
半端に見えないで生殺しよりは丸見えの方が良い。」
俺が高校の生徒会役員だった頃に実際にあった投書
色んな意味で腐った学校だった
本当かどうかはさておき、想像すると笑える
- 関連記事
-
- ピカチュリン (2008/07/21)
- 日本はじまったなー (2008/07/14)
- ベルセルク (2008/07/01)
OLSにぶつけて来るという予想は大ハズレ（T_T
So it's been almost three months since 2.6.25 (87 days to be exact, I
think), making this a longer-than-usual release cycle. Or maybe it just
feels that way, and we're always getting close to three months these days.
But it's out there now. Or rather, the git tree is out there, and the
patch/tar-ball is still uploading as I write this.
The diffs from -rc9 are pretty small, with with the bulk actually being
Documentation updates (almost 80% is just added docs). The rest tensd to
be one-liners for some regressions or otherwise pretty small patches.
Several regressions did get fixed in the last few days, thanks to
everybody involved.
dirstat since -rc9:
3.3% Documentation/networking/
78.5% Documentation/
2.5% arch/
2.4% drivers/net/wireless/
4.0% drivers/net/
2.0% drivers/usb/host/
2.1% drivers/usb/
9.4% drivers/
2.0% fs/
3.6% net/
and dirstat for the whole release since 2.6.25 (yeah, Documentation
doesn't even show up in the latter :^):
4.9% arch/arm/
9.0% arch/powerpc/configs/
11.8% arch/powerpc/
28.7% arch/
5.0% drivers/media/video/
9.2% drivers/media/
5.5% drivers/net/sk98lin/
6.6% drivers/net/wireless/
17.8% drivers/net/
4.8% drivers/s390/net/
5.3% drivers/s390/
49.7% drivers/
6.4% include/
5.1% net/
Have fun,
Linus
---
Alan Stern (1):
[SCSI] erase invalid data returned by device
Alessandro Zummo (1):
rtc-fm3130: fix chip naming
Andres Salomon (1):
ov7670: clean up ov7670_read semantics
Andrew Morton (1):
tcp: net/ipv4/tcp.c needs linux/scatterlist.h
Andrey Vagin (1):
ipv6: fix race between ipv6_del_addr and DAD timer
Anthony Liguori (1):
x86: KVM guest: Add memory clobber to hypercalls
Bartlomiej Zolnierkiewicz (2):
ide: add __ide_default_irq() inline helper
it8213: fix return value in it8213_init_one()
Ben Hutchings (1):
ipv4: fib_trie: Fix lookup error return
Benjamin Herrenschmidt (1):
powerpc: Fix unterminated of_device_id array in legacy_serial.c
Brian King (1):
[SCSI] ipr: Fix HDIO_GET_IDENTITY oops for SATA devices
Dan Williams (1):
md: ensure all blocks are uptodate or locked when syncing
Daniel Guilak (3):
kernel/printk.c: Made printk_recursion_bug_msg static.
kernel/kprobes.c: Made kprobe_blacklist static.
arch/x86/kernel/.gitignore: Added vmlinux.lds to .gitignore file because it shouldn't be tracked.
Darren Jenkins (4):
drivers/net/wireless/iwlwifi/iwl-3945.c Fix type issue on 64bit
crypto: tcrypt - Fix memory leak in test_cipher
drivers/char/pcmcia/ipwireless/hardware.c fix resource leak
drivers/isdn/i4l/isdn_common.c fix small resource leak
Dave Chinner (1):
Fix reference counting race on log buffers
David Gibson (1):
Correct hash flushing from huge_ptep_set_wrprotect()
David Howells (2):
netfilter: nf_nat_snmp_basic: fix a range check in NAT for SNMP
frv: fix irqs_disabled() to return an int, not an unsigned long
Denis V. Lunev (2):
netlabel: netlink_unicast calls kfree_skb on error path by itself
ipv6: missed namespace context in ipv6_rthdr_rcv
Dmitry Adamushko (3):
sched: fix cpu hotplug
slub: Fix use-after-preempt of per-CPU data structure
cpusets, hotplug, scheduler: fix scheduler domain breakage
Eric W. Biederman (1):
serial8250: sanity check nr_uarts on all paths.
Eugene Surovegin (1):
rapidio: fix device reference counting
Firat Birlik (1):
zd1211rw: add ID for AirTies WUS-201
Guy Cohen (1):
mac80211: move netif_carrier_on to after ieee80211_bss_info_change_notify
Herbert Xu (1):
crypto: chainiv - Invoke completion function
Hugh Dickins (1):
exec: fix stack excutability without PT_GNU_STACK
Ihar Hrachyshka (1):
libertas: fix memory alignment problems on the blackfin
Ivo van Doorn (2):
mac80211: Only flush workqueue when last interface was removed
rt2x00: Disable synchronization during initialization
J. Bruce Fields (1):
Documentation: clarify tcp_{r,w}mem sysctl docs
James Bottomley (3):
[SCSI] mptspi: fix oops in mptspi_dv_renegotiate_work()
[SCSI] fusion: default MSI to disabled for SPI and FC controllers
[SCSI] bsg: fix oops on remove
Jan-Bernd Themann (3):
ehea: fix might sleep problem
ehea: add MODULE_DEVICE_TABLE
ehea: fix race condition
Jaya Kumar (1):
fbdev: bugfix for multiprocess defio
Jeff Dike (1):
[UML] fix gcc ICEs and unresolved externs
Jeff Layton (2):
cifs: fix inode leak in cifs_get_inode_info_unix
cifs: fix wksidarr declaration to be big-endian friendly
Jeff Mahoney (1):
reiserfs: discard prealloc in reiserfs_delete_inode
Jesse Barnes (1):
Revert "PCI: Correct last two HP entries in the bfsort whitelist"
Jiri Pirko (1):
Documentation/HOWTO: correct wrong kernel bugzilla FAQ URL
John W. Linville (1):
hostap_cs: correct poor NULL checks in suspend/resume routines
Jon Smirl (1):
rtc-pcf8563: add chip id
Julius Volz (1):
irda: Fix netlink error path return value
Kai Krakow (1):
Added Targa Visionary 1000 IDE adapter to pata_sis.c
Krzysztof Halasa (1):
Add missing skb->dev assignment in Frame Relay RX code
Laurent Pinchart (1):
fs_enet: restore promiscuous and multicast settings in restart()
Li Zefan (2):
devcgroup: always show positive major/minor num
devcgroup: fix permission check when adding entry to child cgroup
Linus Torvalds (7):
Revert "USB: don't explicitly reenable root-hub status interrupts"
vsprintf: split out '%s' handling logic
vsprintf: split out '%p' handling logic
vsprintf: add infrastructure support for extended '%p' specifiers
vsprintf: add support for '%pS' and '%pF' pointer formats
sched: fix cpu hotplug, cleanup
Linux 2.6.26
Luis Carlos Cobo (1):
zd1211rw: stop beacons on remove_interface
Marcin Obara (1):
tpm: add Intel TPM TIS device HID
Mark Fasheh (1):
ocfs2: Fix flags in ocfs2_file_lock
Mark McLoughlin (1):
KVM: IOAPIC: Fix level-triggered irq injection hang
Mark Rustad (1):
IPMI: return correct value from ipmi_write
Mattias Nissler (1):
rc80211_pid: Fix fast_start parameter handling
Max Krasnyansky (1):
tun: Persistent devices can get stuck in xoff state
Michael Buesch (1):
ssb-pcicore: Fix IRQ-vector init on embedded devices
Michael Karcher (1):
x86: fix ldt limit for 64 bit
Milton Miller (1):
tcp: correct kcalloc usage
Nick Piggin (2):
[S390] protect _PAGE_SPECIAL bit against mprotect
Fix PREEMPT_RCU without HOTPLUG_CPU
Octavian Purdila (1):
tcp: fix a size_t < 0 comparison in tcp_read_sock
Oliver Hartkopp (1):
can: add sanity checks
Patrick McHardy (2):
bridge: fix use-after-free in br_cleanup_bridges()
netfilter: nf_conntrack_tcp: fix endless loop
Paul Gortmaker (1):
rtc: fix reported IRQ rate for when HPET is enabled
Philipp Zabel (1):
pxamci: fix byte aligned DMA transfers
Rick Farrington (1):
iwlwifi: fix incorrect 5GHz rates reported in monitor mode
Robert Richter (1):
OProfile kernel maintainership changes
Roland Dreier (2):
ehea: Access iph->tot_len with correct endianness
pasemi_mac: Access iph->tot_len with correct endianness
Sathya Narayanan (2):
ibm_newemac: Fixes kernel crashes when speed of cable connected changes
ibm_newemac: Fixes entry of short packets
Sergei Shtylyov (1):
palm_bk3710: fix IDECLK period calculation
Shane McDonald (1):
[MIPS] Atlas, decstation: Fix section mismatches triggered by defconfigs
Steffen Klassert (1):
xfrm: Add a XFRM_STATE_AF_UNSPEC flag to xfrm_usersa_info
Stephen Hemminger (1):
ip: sysctl documentation cleanup
Steve Wise (1):
RDMA/cxgb3: Fix regression caused by class_device -> device conversion
Steven Rostedt (1):
ftrace: Documentation
Sunil Mushran (1):
ocfs2/dlm: Fixes oops in dlm_new_lockres()
Takashi Iwai (1):
Fix broken fix for fsl-diu-db
Tejun Heo (1):
libata-acpi: filter out DIPM enable
Thomas Bogendoerfer (1):
[MIPS] Fix 32bit kernels on R4k with 128 byte cache line size
Tobias Diedrich (1):
forcedeth: fix lockdep warning on ethtool -s
Trond Myklebust (3):
NFS: Fix readdir cache invalidation
SUNRPC: Fix a double-free in rpcbind
SUNRPC: Fix an rpcbind breakage for the case of IPv6 lookups
Uwe Kleine-König (1):
Fix name of Russell King in various comments
Venkatesh Pallipadi (1):
x86: fix /dev/mem compatibility under PAT
Ville Syrjala (1):
irda: New device ID for nsc-ircc
Vitaly Bordug (1):
powerpc: Add missing reference to coherent_dma_mask
Vlad Yasevich (2):
sctp: Mark the tsn as received after all allocations finish
sctp: Add documentation for sctp sysctl variable
Vladimir Koutny (1):
mac80211: don't report selected IBSS when not found
Wang Chen (1):
irda: via-ircc proper dma freeing
Zhang Rui (1):
libata-acpi: don't call sleeping function from invalid context
Zhu Yi (1):
iwlwifi: drop skb silently for Tx request in monitor mode
[email protected] (1):
libertas: support USB persistence on suspend/resume (resend)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- 関連記事
-
- [RFC] Improved versioned pointer algorithms (2008/07/14)
- linux 2.6.26 (2008/07/14)
- うむ (2008/07/14)
計画を立てていたんだけど、今日のAndrewからのメールを見るとどうやら達成したらしい。
2.6.26のリリースが遅れているのと（たぶんLinusはOLSにぶつける為にわざと遅らせている）
パッチの内実が、本人の全然知らないところでCCedに入っていたヤツ多数なので、
手放しに喜べない部分もあるが、まあ、そのへんは今後改善だな
- 関連記事
-
- linux 2.6.26 (2008/07/14)
- うむ (2008/07/14)
- いや・・PowerPCのFixをCCされても・・・ (2008/07/14)
・・・が、しかし、PowerPCのコードなんか送られても、まったくレビューできないのであった（苦笑
- 関連記事
-
- うむ (2008/07/14)
- いや・・PowerPCのFixをCCされても・・・ (2008/07/14)
- さよならpagemap (2008/07/08)
組み込み屋さん涙目
・・・といいたいところだが、LKMLでLinusの意見が黙って無視されるのは良くある事なので油断できない（そしてLinusはすねることになる）
On Fri, 4 Jul 2008, Andrew Morton wrote:
> int pagecount;
> int ret = -ESRCH;
> + static struct mm_walk pagemap_walk;
>
...
>
> + pagemap_walk.pmd_entry = pagemap_pte_range;
> + pagemap_walk.pte_hole = pagemap_pte_hole;
> + pagemap_walk.mm = mm;
> + pagemap_walk.private = ±
> +
No can do. You have one single pagemap_walk, but perhaps multiple users,
who all disagree about what it should contain.
Quite frankly, I think we should just remove the whole f*cking crap. I
think it's also potentially a security hole to give physical page
information and swap info - even if it's just your own pages.
Matt, can you explain what the point was of this whole thing? I'm really
_this_ close to just removing the POS right now. It's been a big source of
bugs, and it looks entirely pointless.
Linus
- 関連記事
-
- いや・・PowerPCのFixをCCされても・・・ (2008/07/14)
- さよならpagemap (2008/07/08)
- ipcsコマンドの翻訳が間違っている件について (2008/07/08)