なんかものすごい他人事モードなんですが、GWなのでもうすぐ。ありえない。
- 関連記事
これで、最小コンパイル時間が満喫できる。らしい
As it has been brought up last Kernel Summit, we want to make it easier
for those that report bugs to build their own kernels, and maybe even
bisect with git. Some of these people are not programmers and do not
understand the complexity of the configuration options. But to compile
a distribution configured kernel on their boxes can take hours.
This patch series comes to the rescue. I wrote the first instance of
streamline config when I bought a new box in 2005 and got frustrated
with finding all the necessary configurations to boot it. It is a
small (yet powerful) perl script.
Here's what it does:
* Reads the modules that are load by using lsmod.
* Reads all Makefiles to map modules to CONFIG_* options
* Reads the Kconfig files to find dependencies and selects
* Figures out what CONFIGS are needed to compile the loaded modules
* Reads the .config and prints out a version with all module configurations
that not needed, disabled.
The next two patches add options to make.
localmodconfig - this will run streamline_config.pl on the .config file
and replace it at the end.
localyesconfig - this will do the same as localmodconfig but will also
sed -i s/=m/=y/ to turn all modules to core. It will also run
the 'make oldcondfig' to fix it up and let the user handle
andything that was changed by converting a module to core.
Anyway, this is now in git and as a series of patches here. My git tree
is based off of the latest Linus git tree.
Have fun!
-- Steve
The following patches are in:
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git
branch: kconfig
Steven Rostedt (3):
kconfig: add streamline_config.pl to scripts
kconfig: make localmodconfig to run streamline_config.pl
kconfig: add make localyesconfig option
----
scripts/kconfig/Makefile | 24 +++-
scripts/kconfig/streamline_config.pl | 291 ++++++++++++++++++++++++++++++++++
2 files changed, 314 insertions(+), 1 deletions(-)
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- 関連記事
-
- debianはglibc捨ててeglibcに移行するよ (2009/05/06)
- [PATCH 0/3] removing unwanted module configs (2009/04/30)
- TUZ が revertされました (2009/04/28)
Revert "linux.conf.au 2009: Tuz"
This reverts commit 8032b526d1a3bd91ad633dd3a3b5fdbc47ad54f1.
Hey, it was only meant to be a single release. Now they can all die as
far as I'm concerned.
[ Just kidding. They're cute and cuddly.
Except when they have horrible nasty facial diseases. Oh, and I guess
they're not actually that cuddly even when disease-free. ]
Signed-off-by: Linus Torvalds
- 関連記事
-
- [PATCH 0/3] removing unwanted module configs (2009/04/30)
- TUZ が revertされました (2009/04/28)
- branch hint prefixは使うべきではない (2009/04/24)
From: Alexey Dobriyan
Date: Sun, 29 Mar 2009 21:56:42 +0400
> Ingo, what are you doing?
Alexey, please crawl back into your cave.
Enough already.
Alexey Dobriyan: やあ Ingo、このパッチはこうすればもっと改善できるんじゃないかな
David Miller: お前の星にカエレ(・A・)。このままで十分だよ
David ひでー
- 関連記事
-
- [英語] up in the air (2009/11/02)
- [英語] crawl back into your cave (2009/04/28)
- [英語] キャッチ22 (2009/04/25)
> > I agree that we need to be frugal with the addition of trace points. But
> > I don't think the bugs that can be solved with this is always reproducible
> > by the developer.
> >
> > If you have a distribution kernel that is running at a customers location,
> > you may not have the privilege of shutting down that kernel, patching the
> > code, recompiling and booting up this temporary kernel. It would be nice
> > to have strategic locations in the kernel where we can easily enable a
> > trace point and monitor what is going on.
> >
> > If the customer calls and tells you there's some strange performance
> > issues when running such and such a load, it would be nice to look at
> > things like workqueues to analyze the situation.
>
> Would it? What's the probability that anyone anywhere will *really*
> solve an on-site problem using workqueue tracepoints? Just one person?
>
> I think the probability is quite small, and I doubt if it's high enough
> to add permanent code to the kernel.
>
> Plus: what we _really_ should be looking at is
>
> p(someone uses this for something) -
> p(they could have used a kprobes-based tracer)
This is starting to sound a lot like catch 22. We don't want it in the
kernel if nobody is using it. But nobody is using it because it is not in
the kernel.
Andrew Morton: そんなにトレースポイントって必要か? kprobe based tracerでいいじゃん
Steven Rostedt: キャッチ22的な状況だね。誰も使わないトレースポイントは入れたくないが
カーネルにマージしないかぎりは誰も使わないに決まってる。
Wikipediaのキャッチ22の項
を見ると要するにパラドクスとかジレンマとかそういうニュアンスらしい。
- 関連記事
-
- [英語] crawl back into your cave (2009/04/28)
- [英語] キャッチ22 (2009/04/25)
- [英語] Bob's your uncle (2009/04/17)
I think that's probably the dominant effect on x86 systems, because
Intel doesn't recommend using the branch hint prefixes as far as I can
tell (their consumption of icache space outweighs any benefit of priming
the predictor).
イマドキのx86はbranch hint prefixを使うとicacheを浪費するから非推奨なんだと
ほほー
- 関連記事
-
- TUZ が revertされました (2009/04/28)
- branch hint prefixは使うべきではない (2009/04/24)
- IBMのLinux記事を読んで (2009/04/24)
http://www.ibm.com/developerworks/jp/linux/library/l-kernel-advances/?ca=drs-jp
うむ、勝ったな ← うぬぼれすぎ
- 関連記事
-
- branch hint prefixは使うべきではない (2009/04/24)
- IBMのLinux記事を読んで (2009/04/24)
- Debug Hacks Conference (2009/04/23)
なんか、僕がNAKしたからOOM killerの改善が入らなかったとか言ってたが全然記憶にないぞ。
誰か詳細情報プリーズ
あと、なんか献本とかはきそうにないので、今度買ってきて書評でも書こうかと思った
- 関連記事
-
- IBMのLinux記事を読んで (2009/04/24)
- Debug Hacks Conference (2009/04/23)
- ext4のfsckは32TBで23分 (2009/04/23)
Now that 64-bit e2fsck can run to completion on a (newly-minted, never
mounted) filesystem, here are some numbers. They must be taken with
a large grain of salt of course, given the unrealistict situation, but
they might be reasonable lower bounds of what one might expect.
First, the disks are 300GB SCSI 15K rpm - there are 28 disks per RAID
controller and they are striped into 2TiB volumes (that's a limitation
of the hardware). 16 of these volumes are striped together using LVM, to
make a 32TiB volume.
The machine is a four-slot quad core AMD box with 128GB of memory and
dual-port FC adapters.
The filesystem was created with default values for everything, except
that the resize_inode feature is turned off. I cleared caches before the
run.
# time e2fsck -n -f /dev/mapper/bigvg-bigvol
e2fsck 1.41.4-64bit (17-Apr-2009)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/mapper/bigvg-bigvol: 11/2050768896 files (0.0% non-contiguous), 128808243/8203075584 blocks
real 23m13.725s
user 23m8.172s
sys 0m4.323s
Most of the time (about 22 minutes) is in pass 5. I was taking snapshots
of
/proc/{pid of e2fsck}/statm
every 10 seconds during the run[1]. It starts out like this:
27798 3293 217 42 0 3983 0
609328 585760 263 42 0 585506 0
752059 728469 272 42 0 728237 0
752059 728469 272 42 0 728237 0
752059 728469 272 42 0 728237 0
752059 728469 272 42 0 728237 0
752059 728469 272 42 0 728237 0
752059 728469 272 42 0 728237 0
752059 728469 272 42 0 728237 0
717255 693666 273 42 0 693433 0
717255 693666 273 42 0 693433 0
717255 693666 273 42 0 693433 0
....
and stays at that level for most of the run (the drop occurs a short
time after pass 5 starts). Here is what it looks like at the end:
....
717255 693666 273 42 0 693433 0
717255 693666 273 42 0 693433 0
717255 693666 273 42 0 693433 0
717499 693910 273 42 0 693677 0
717499 693910 273 42 0 693677 0
717499 693910 273 42 0 693677 0
So in this very simple case, memory required tops out at about 3 GB for the
32Tib filesystem, or 0.4 bytes per block.
Nick
[1] The numbers are numbers of pages. The format is described in
Documentation/filesystems/proc.txt:
Table 1-2: Contents of the statm files (as of 2.6.8-rc3)
..............................................................................
Field Content
size total program size (pages) (same as VmSize in status)
resident size of memory portions (pages) (same as VmRSS in status)
shared number of pages that are shared (i.e. backed by a file)
trs number of pages that are 'code' (not including libs; broken,
includes data segment)
lrs number of pages of library (always 0 on 2.6)
drs number of pages of data/stack (including libs; broken,
includes library text)
dt number of dirty pages (always 0 on 2.6)
..............................................................................
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
- 関連記事
-
- Debug Hacks Conference (2009/04/23)
- ext4のfsckは32TBで23分 (2009/04/23)
- [rfc] built-in native compiler for Linux? (2009/04/22)
むしろ最大の疑問はなぜ自分が宛先に入っているのかという・・・・
コメントのつけようがないよな。どう考えても
* Steven Rostedtwrote:
> I think it was Ingo that let out the idea, and I'm starting to
> like it.
>
> Perhaps we should fork off gcc and ship Linux with its own
> compiler. This way we can optimize it for the kernel and not worry
> about any userland optimizations.
I didnt suggest forking GCC. A kernel-special GCC would likely just
become an inferior fork of GCC over time and would fizzle out.
There's 100 times more user-space code than kernel-space code and
GCC is too large and too legacy-laden to really be appropriate for
that purpose.
What i think makes sense is to build a _new_ precompiler / compiler
/ assembler / linker combo for Linux, from scratch, hosted in the
kernel proper.
In the past 15 years of Linux we've invested a lot of time and
effort into working around and dealing with compiler crap. We wasted
a lot of opportunities waiting years for sane compiler features to
show up. We might as well have invested that effort into building
our own compiler and could stop bothering about externalities. The
Linux kernel project certainly involves the right kind of people who
could make something like this happen.
A good technical basis for that would be Sparse, and it could start
by acting as a drop-in replacement for CPP and it could feed its
output to GCC with little changes. Sparse is small, has a very tidy
code base and is already useful today as an extended static source
code checker.
The Sparse codebase could move into the kernel proper, under
linux/sparse/ or so - so the preprocessor/compiler and the kernel
could be in precise feature and bugfix lock-step with no artificial
external synchronization.
We have a lot of annoying preprocessor limitations that Sparse could
help with straight away. We'd also get Sparse type checking by
default. So it's helpful even without any code generator support.
Then, if this model works out, we could experiment with adding a
code generator backend to Sparse. I think Jeff Garzik experimented
with that in the past with some surprisingly quick (but incomplete)
results.
Since most of the performance-critical code in Linux is
hand-optimized already, we dont even need all that many complex,
exotic optimizations - we want to encourage common-sense coding
practices. Furthermore, a lot of optimizations in GCC are driven by
SPECint and SPECfp benchmarketing, with little practical relevance
to 99% of the apps, including the kernel.
There would always be an 'output to GCC' kind of compatible build
channel as well, for CPU architectures that dont have native code
generator support yet. We'd also do that to generally keep our
options open, in case we are wrong about it all or in case some even
better compiler project pops up.
Ingo
- 関連記事
-
- ext4のfsckは32TBで23分 (2009/04/23)
- [rfc] built-in native compiler for Linux? (2009/04/22)
- 米Oracle、Sun Microsystemsを買収 (2009/04/20)
だそうな。
ディストリビュータ・ビジネスを始めたオラクル的には欲しいのはサンの顧客だろうから、Solarisの未来は暗いな
- 関連記事
-
- [rfc] built-in native compiler for Linux? (2009/04/22)
- 米Oracle、Sun Microsystemsを買収 (2009/04/20)
- [Ksummit-2009-discuss] Kernel Summit: Call for nominations (2009/04/20)
なんか第一候補が発表されたらしい。
日本人っぽいのを適当にピックアップ
Akinobu Mita <akinobu.mita at gmail.com>
Atsushi Nemoto <anemo at mba.ocn.ne.jp>
FUJITA Tomonori <fujita.tomonori at lab.ntt.co.jp>
KAMEZAWA Hiroyuki <kamezawa.hiroyu at jp.fujitsu.com>
Kenji Kaneshige <kaneshige.kenji at jp.fujitsu.com>
KOSAKI Motohiro <kosaki.motohiro at jp.fujitsu.com>
Hiroshi Shimamoto <h-shimamoto at ct.jp.nec.com>
Isaku Yamahata <yamahata at valinux.co.jp>
Magnus Damm <damm at igel.co.jp>
YOSHIFUJI Hideaki <yoshfuji at linux-ipv6.org>
(あ、節子、マグナスは日本人ちゃうで)
海外さんや、原田さんは残念っぽい。
富士通多いな。でも、ここから半分に減るので、ちょっと生き残れそうにない。
- 関連記事
-
- 米Oracle、Sun Microsystemsを買収 (2009/04/20)
- [Ksummit-2009-discuss] Kernel Summit: Call for nominations (2009/04/20)
- glibc 2.10 news (2009/04/18)
でとりあげられてるコンテストの優勝作品がマジキチらしい(ほめ言葉)
こんだけぐりぐり動いて4KB(4Mちゃうで)らしい。
http://www.pouet.net/prod.php?which=52938 からダウンロードできるらしい
- 関連記事
-
- 明治大学 (2009/04/30)
- ドイツのォォォォ、科学力はァァァァァ (2009/04/18)
- 胃痛がひどい (2009/04/17)
時期的に考えると、Fedora11/RHEL6用のlibcになるのかな?
http://udrepper.livejournal.com/20948.html
以下、要約
・strchrの実装を変えたよ。
strchrは規格上
char *strchr(const char *, int)
のようなプロトタイプをもつけども、これはCがオーバーローディングをサポートしない事による制限で
本来は
char *strchr(char *, int)
const char *strchr(const char *, int)
の2つをサポートするべき。gccトリックによってCでこれを実現したよ。
・C++ 201x support
デストラクタを呼ばない quick_exit() とそれ用のat_exit()の変種、at_quick_exit()が追加されたので実装したよ
int at_quick_exit(void (*)(void))
void quick_exit(int)
・DNS NSS improvement
2.9でIPv4とIPv6の名前解決をパラレルにやるようにして性能向上させたんだけど、腐れDNSが狂った返事をしたときが問題だった。そういう時のフォールバック論理を実装したよん
・Use NSS in libcrypt
※ よくわからん。なんかの認証の問題なの?
・printf hooks
decimal floating point computationsの規格をつくったバカがいるけどサポートしたくないから、
代わりに汎用のprintf フックを作ったぜ。
好きなmodifierを実装してくれ
・malloc scalability (※1)
いままでは、per-core memory pool をエミュレートしてたよ。んで、malloc時に競合したら
(trylockが失敗したら)新しいpoolをつくってた。
これは、競合が発生しないかぎり2つのスレッドが同じpoolを使うのでfalse sharing (※2)に
よって、 キャッシュ競合が発生して性能が落ちてた。だから、発想を転換して per-threadな
pool を作る事にしたよ。
でも、無造作にper-thread poolを作ると32bit machineでアドレス空間が足りなくなるので
core数 x2 (64bitではcore数 x8) にpool 数を制限する論理をいれたよ。
core数のチェックは/proc/statを読む必要があり重い処理なので出来る限り遅延させるよ。
この変更はmemory pool数を増加させると思うけど、古いメカニズムはプール数に上限が
なかったので、競合がたくさん発生した場合のワーストケースは古いほうが悪かった。だから
これは改善なんだぜい
dlmallocをglibcに移植した当時(1995)はメモリ64Mとかでアドレス空間の問題なんで全然
考えてなかった。
あと、free関数でいらないと判断できるときは、lockをとらないようにしたよ(※3)
内部での測定では、すごい性能改善が観測されているぜ
※1 ようするに昔、話題になったMySQLとの相性の悪さを直したってことだと思う。Google Malloc
に変えたら性能上がった。とか話題になったよね
※2 こういうのはtrue sharingだろーが。false sharingってのは論理上は同じ変数へのアクセスはないんだけれど、2つの変数が同じCPUキャッシュラインに載る事により、競合する状態だ。
glibc mallocは同じ変数さわっとるやんけ。
※3 おさらい。昔のglibcの論理は競合をmallocでtrylock使うことにより検出。freeは普通にlock取ってた。そうすると、ライブラリの都合とかでmalloc呼び出し元が共通mutexをとってると、mallocでは絶対競合せずに、freeで競合しまくる。というのがMySQL問題。だから、1.競合検出をまたずに別poolに追い出す。 2.不要なfreeのlockをはずす が重要になってくる。ソース読んでないので誤解してるかもしれんが
・Information about malloc
glibcがmallinfoと呼んでいるSysVの隠し機能がある。これはmallocの統計値(アロケートメモリ量、トータルアドレス空間、等)が取得できる。
でも、SysVの定義が腐っていて 2^31 以上の値がハンドルできないので、64bit環境では全然使い物にならなかった。
なので、構造体をexportするのはもうやめて、代わりに取得関数を提供する事にしたよ。
・Automatic use of optimized function
SSE4.2 (Nehalem)ではstring命令が追加されてるけど、strlenとかstrchrとかの個々の関数でSSE命令の有無を判定するなんてばかげてるぜ。
この判定で浪費した数十サイクルはメリットを台無しにしてしまうから。
その代わりに新しいELFシンボルを導入して、シンボルルックアップ時に1回だけ判定、SSEバージョンと通常バージョンのどちらをルックアップするか変えるよ
- 関連記事
Don't worry about the new default journaling mode for ext3 planned for 2.6.30 (data=writeback, which is much faster than the old default, data=ordered, but has enormous security and data integrity problems). No distro would ship this as the default. The only way it could happen at Red Hat is over the dead bodies of the security team, who, let me tell you, keep an eagle eye on file system data leaks like this.
超訳:
新しいデフォルトについて心配する必要はないよ。data=writebackをデフォルトにして出荷するディストロなんかありえないから。Redhatのセキュリティチームが死に絶える事がない限りはね。
Valerie Aurora はLinkedIn曰く
* Senior Software Engineer at Red Hat
* Director at VAH Consulting, LLC
というポストの人なので信頼できる情報なのではないかしら
- 関連記事
-
- glibc 2.10 news (2009/04/18)
- Redhatプロダクトではext3のデフォルトモードをwritebackに変えないよ (2009/04/18)
- 続々 sysfs の poll の件 (2009/04/18)
メールサブジェクトが
[GIT PATCH] driver core patches for 2.6.31-rc2
と三ヶ月未来に生きているぜ状態だったので一瞬混乱したが
- 関連記事
-
- Redhatプロダクトではext3のデフォルトモードをwritebackに変えないよ (2009/04/18)
- 続々 sysfs の poll の件 (2009/04/18)
- NTT OSSセンタについてちょっと調べてみた (2009/04/17)
「だいじょうぶ、問題ない、ほら簡単、楽勝だろう」 という意味らしい
例文:
>
>> -__ending_string(name, src)
ftrace で __ending_string() という新しいタイプを追加したくてだな。やっぱり固定長配列しかないのは不便なのだよ。トレースデータは先頭にサイズが入っているんだから、最後のメンバだけは可変長にしてもサイズは逆算できるはずで・・・
とかいう議論をしている。
> > can't we simply do __string(name, src) and output something like:
> >
> > struct {
> > u16 size;
> > char str[0];
> > } name;
> >
> > That would get rid of this __ending_ wart.
__ending なしの __string() にできないの? こんな風に
> Hmm, I don't understand.
> Such a thing doesn't seem to work. Once we fill the string it would
> override the fields that
> follow it if it's not at the end.
うむむ、よく分からん。
それは動かんように見えるぞ。その構造体をラストメンバ以外で使ったら後続メンバをオーバライドしちゃうじゃん
Just grow the thing to fit whatever string length -- rather common
pattern:
struct foo {
int length;
char data[0];
};
struct foo *bar = kmalloc(sizeof(struct foo) + data_size);
いやいや、kmallocのサイズを変えるだけじゃん
and bob's your uncle.
楽勝だろ?
とかとか。
このあと、トレースでkmallocは使えねーんだよバーヤバーヤ。とか議論があった後以下の仕様になった。
__field(int, foo);
__string(bar);
__field(int, foo2);
__string(bar2);
__field(int, foo3);
こんな感じで適当にメンバを宣言していく
struct plop {
int foo;
char *bar;
int foo2;
char *bar2;
int foo3;
char data[0];
}
これが、こんな構造体に変換される。でbarとかba2はdata配列のどこかのインデックスをポイントしている。
で、呼び出し方はこう
size = sizeof(struct plop);
size += strlen(bar) + 1;
size += strlen(bar2) + 1;
event = ring_buffer_lock_reserve(size);
offset = sizeof(struct plop);
my_plop.bar = (char *)offset;
offset += strlen(bar) + 1;
my_plop.bar2 = (char *)offset;
memcpy(&event, &my_plop, sizeof(struct plop));
memcpy(&event + my_plop.bar, bar, strlen(bar)+1);
memcpy(&event + my_plop.bar2, bar2, strlen(bar2)+1);
ring_buffer_unlock();
- 関連記事
-
- [英語] キャッチ22 (2009/04/25)
- [英語] Bob's your uncle (2009/04/17)
- [英語] last resort (2009/03/15)
明日、休日出勤決定やんけ。
- 関連記事
-
- ドイツのォォォォ、科学力はァァァァァ (2009/04/18)
- 胃痛がひどい (2009/04/17)
- 胃痛 (2009/04/08)
■Linux Kernel 開発/改善への貢献
年度 Linux Kernel 採用数 Red Hat Bugzilla 報告数
2008年度 22件 7件
2007年度 24件 6件
2006年度 11件 3件
(2009/01/13時点NTT OSSセンタによる集計データに基づく)
どうもまともにOSSに取り組んでいる場所ではなさげ。コミュニティに普通に参画したら年間500件とかになるはず。ソースは自分の会社。
なんぼなんでも、能力が20倍の差はありえないから、上司の理解がないとしか思えん。
中の人がちょっとカワイソス
- 関連記事
-
- 続々 sysfs の poll の件 (2009/04/18)
- NTT OSSセンタについてちょっと調べてみた (2009/04/17)
- マルチスレッドプログラムはforkしたらexecするまでの間はasync-signal-safe な関数しか呼んではいけない (2009/04/16)
このへんの資料みながら。
SUSによると、マルチスレッドプログラムはforkしたあと、async-signal-safeオペレーションしか、しちゃダメということになっている。
特に glibc とかだと、規格を守らない奴がバカ。ってスタンスなので、libc 呼び出し中にforkしたらハングしても文句はいえない。
libc の中でmutex使っていけないというルールはないから。
http://www.opengroup.org/onlinepubs/009695399/functions/fork.html
A process shall be created with a single thread. If a multi-threaded process calls fork(), the new process shall contain a replica of the calling thread and its entire address space, possibly including the states of mutexes and other resources. Consequently, to avoid errors, the child process may only execute async-signal-safe operations until such time as one of the exec functions is called. [THR] [Option Start] Fork handlers may be established by means of the pthread_atfork() function in order to maintain application invariants across fork() calls. [Option End]
When the application calls fork() from a signal handler and any of the fork handlers registered by pthread_atfork() calls a function that is not asynch-signal-safe, the behavior is undefined.
要約:
fork時はスレッドは呼び出しスレッドしかコピーされない。でもmutexやらなんやらの状態はコピーされてしまう。必然的にexecute async-signal-safe な操作しかしちゃだめってこった。
でも、実際問題として、世の中には規格を調べない人がいっぱいいるので・・・
- 関連記事
-
- NTT OSSセンタについてちょっと調べてみた (2009/04/17)
- マルチスレッドプログラムはforkしたらexecするまでの間はasync-signal-safe な関数しか呼んではいけない (2009/04/16)
- 続 @ITのmeminfoの見方の説明が完全に間違っている件について (2009/04/16)
続く drop_caches の説明も間違ってる
0. デフォルト状態に戻す場合
# echo 0 > /proc/sys/vm/drop_caches
と書かれているが、当該箇所のソースは以下である
linux/fs/drop_caches.c
int drop_caches_sysctl_handler(ctl_table *table, int write,
struct file *file, void __user *buffer, size_t *length, loff_t *ppos)
{
proc_dointvec_minmax(table, write, file, buffer, length, ppos);
if (write) {
if (sysctl_drop_caches & 1)
drop_pagecache();
if (sysctl_drop_caches & 2)
drop_slab();
}
return 0;
}
要するに、0なんか書き込んでも無視されているだけである。drop_cachesはいかなる状態も管理なんかしていない。
ただのキャッシュ破棄用のインターフェースにすぎない
かつ、RHELだと古いバージョンはバグがあってOSがハングする可能性があるので、安易に drop_caches を勧めるのもどうかと思う。
- 関連記事
-
- マルチスレッドプログラムはforkしたらexecするまでの間はasync-signal-safe な関数しか呼んではいけない (2009/04/16)
- 続 @ITのmeminfoの見方の説明が完全に間違っている件について (2009/04/16)
- @ITのmeminfoの見方の説明が完全に間違っている件について (2009/04/16)
Activeはページキャッシュや無名ページ(注3)のうち、最近利用したり、まだストレージとの同期が取れていない「捨てられない」ページです。Inactiveは、同じくページキャッシュや無名ページのうち、最後にアクセスされてからある程度時間がたち、ストレージとの同期も完了していて、すぐに捨てられるページです。よって、/proc/meminfoの出力でいうところの MemFreeとInactiveを足すことで確実に利用可能なメモリ量を算出することができます。
(実際に利用可能なメモリ量)≒(MemFree+Inactive)
この値を利用し、一定量を下回らないようにするのが、簡単・確実なメモリ利用率監視法といえます。
間違ってる。完全に。
たぶんNTT OSSセンタという所は顧客と直接取引がある部署ではないのではないかと推測。さすがにこんなデタラメを説明する所があるとは信じがたい。
まず、ActiveとInactiveの違いは、メモリ不足発生時にInactiveのほうが先に回収可能性チェックをされる。という意味しかない。
Inactiveにもダーティーページ(ストレージが同期がとれていないページ)やmlockされたページなど捨てられないページは大量に混じっている。
また、Inactiveをチェックして、回収したりActiveに入れなおしたりして減ったInactiveのページ数はActiveからInactiveに落とすことにより、補充されるので、Activeであることも何も保障してない。
- 関連記事
-
- 続 @ITのmeminfoの見方の説明が完全に間違っている件について (2009/04/16)
- @ITのmeminfoの見方の説明が完全に間違っている件について (2009/04/16)
- aio contextはforkで継承されません (2009/04/15)
・リングバッファをmadvise(DONTFORK)しろ
・man forkに加筆しろ
と主張してみたが、どうやら通りそう。
- 関連記事
-
- @ITのmeminfoの見方の説明が完全に間違っている件について (2009/04/16)
- aio contextはforkで継承されません (2009/04/15)
- あれー (2009/04/14)
LinuxとFreeBSDでPOSIX mutexとsemaphoeのスループットを計測したよんというBlog.
・Linuxのmutex(futex)はFreeBSDより1.5倍くらい速いよ
・競合がないときは、なぜかsemaphoeが二倍速いけど意味不明
・まあどちらにしろ、全然スケールしないから、POSIX mutexはコンテンションがほとんどないように
設計しないととんでもないことになるね
- 関連記事
-
- あれー (2009/04/14)
- Linux and FreeBSD POSIX mutexes and semaphores (2009/04/13)
- 最新のクロスコンパイラは毎週あっぷするよん (2009/04/13)
めちゃんこ、いい人やんけ
On Fri, 2009-04-10 12:49:13 +0200, Sam Ravnborgwrote:
> It can...
> I'm after a one-stop place where we can locate cross compilers
> for all architectures that Linux supports so it is a much simpler
> task to actaully try to build our changes for as many architectures
> as we supports.
As long as nobody objects, I'll put snapshot compilers once a week to
http://www.kernel.org/pub/linux/kernel/people/jbglaw/cross_compilers
The first round is uploading right now, it should show up soon.
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de +49-172-7608481
Signature of: The course of history shows that as a government grows, liberty
the second : decreases." (Thomas Jefferson)
- 関連記事
-
- Linux and FreeBSD POSIX mutexes and semaphores (2009/04/13)
- 最新のクロスコンパイラは毎週あっぷするよん (2009/04/13)
- O_REALLYDIRECT (2009/04/11)
- 関連記事
-
- 最新のクロスコンパイラは毎週あっぷするよん (2009/04/13)
- O_REALLYDIRECT (2009/04/11)
- Analog Deviceから開発用ボード送られてきた (2009/04/11)
という意味らしい。
Blackfinなんて初めてみたよ。
- 関連記事
-
- O_REALLYDIRECT (2009/04/11)
- Analog Deviceから開発用ボード送られてきた (2009/04/11)
- [linux-btrfs] Btrfs TODO (2009/04/10)
Hello,
Trying to put together a list of TODO items for btrfs so we can update the wiki
page fully. So far these things are on the list
* Proper ENOSPC handling
* O_DIRECT support (without checksumming)
* AIO support
* Subvolume quotas and inherited space usage information
* Snapshot removal
* QA Suite for automated regression testing
* Reserved space for online fsck and the ability to add storage so that a
* background extent allocation check can proceed
* Additional ioctls to set per-inode attributes (nodatacow, nodatasum, etc)
So I think all of those are still true. Things that I know are being worked on
are
* async block group cacheing - me
* locking changes - Chris
* backref stuff - Yan
Som other things off the top of my head are
* a better way to cache block groups in general, for this I was thinking of a
bitmap or something like that per block group of free space
* space balancing. this will likely need to wait on proper ENOSPC handling
* grub support :)
Thats all that I can think of atm. Add things to the list if you think of them,
and hopefully we can update the wiki early next week. Thanks,
Josef
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
- 関連記事
-
- Analog Deviceから開発用ボード送られてきた (2009/04/11)
- [linux-btrfs] Btrfs TODO (2009/04/10)
- 続 sysfs の poll の件 (2009/04/10)