プロフィール

kosaki

Author:kosaki
連絡先はコチラ

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

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

で、講義をするらしいです。
なんかものすごい他人事モードなんですが、GWなのでもうすぐ。ありえない。

関連記事
雑談 | 【2009-04-30(Thu) 16:54:41】 | Trackback:(0) | Comments:(2)

[PATCH 0/3] removing unwanted module configs このエントリーをはてなブックマークに追加

Steven Rostedt が動作中のカーネルのlsmod情報から、必要なハードウェアのみONの最小 .configを生成してくれるスクリプトを開発した。
これで、最小コンパイル時間が満喫できる。らしい


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/


関連記事
linux | 【2009-04-30(Thu) 16:34:13】 | Trackback:(0) | Comments:(0)

TUZ が revertされました このエントリーをはてなブックマークに追加


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


関連記事
linux | 【2009-04-28(Tue) 14:40:31】 | Trackback:(0) | Comments:(0)

[英語] crawl back into your cave このエントリーをはてなブックマークに追加

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 ひでー



関連記事
英語 | 【2009-04-28(Tue) 13:50:02】 | Trackback:(0) | Comments:(0)

[英語] キャッチ22 このエントリーをはてなブックマークに追加


> > 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の項
を見ると要するにパラドクスとかジレンマとかそういうニュアンスらしい。







関連記事
英語 | 【2009-04-25(Sat) 13:21:58】 | Trackback:(0) | Comments:(0)

branch hint prefixは使うべきではない このエントリーをはてなブックマークに追加


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を浪費するから非推奨なんだと
ほほー


関連記事
linux | 【2009-04-24(Fri) 20:04:51】 | Trackback:(0) | Comments:(0)

IBMのLinux記事を読んで このエントリーをはてなブックマークに追加

IBM developerWorks: 進歩する Linux カーネル
http://www.ibm.com/developerworks/jp/linux/library/l-kernel-advances/?ca=drs-jp


うむ、勝ったな ← うぬぼれすぎ

関連記事
linux | 【2009-04-24(Fri) 18:56:37】 | Trackback:(0) | Comments:(0)

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

原稿締め切り間近で行けなかったので、インターネット中継で見てた。
なんか、僕がNAKしたからOOM killerの改善が入らなかったとか言ってたが全然記憶にないぞ。
誰か詳細情報プリーズ

あと、なんか献本とかはきそうにないので、今度買ってきて書評でも書こうかと思った




関連記事
linux | 【2009-04-23(Thu) 21:16:35】 | Trackback:(0) | Comments:(3)

ext4のfsckは32TBで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


関連記事
linux | 【2009-04-23(Thu) 15:08:50】 | Trackback:(0) | Comments:(0)

草なぎ君が逮捕されたらしい このエントリーをはてなブックマークに追加

さっそくこんな画像が流布されてた。

草なぎ


関連記事
ねた | 【2009-04-23(Thu) 13:01:45】 | Trackback:(0) | Comments:(0)

[rfc] built-in native compiler for Linux? このエントリーをはてなブックマークに追加

Ingoがカーネル専用コンパイラ作ろうぜ。とか世迷い言を言い始めた。
むしろ最大の疑問はなぜ自分が宛先に入っているのかという・・・・

コメントのつけようがないよな。どう考えても

* Steven Rostedt  wrote:

> 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




関連記事
linux | 【2009-04-22(Wed) 19:54:49】 | Trackback:(0) | Comments:(1)

米Oracle、Sun Microsystemsを買収 このエントリーをはてなブックマークに追加

http://journal.mycom.co.jp/news/2009/04/20/061/

だそうな。
ディストリビュータ・ビジネスを始めたオラクル的には欲しいのはサンの顧客だろうから、Solarisの未来は暗いな

関連記事
linux | 【2009-04-20(Mon) 21:53:40】 | Trackback:(0) | Comments:(0)

[Ksummit-2009-discuss] Kernel Summit: Call for nominations このエントリーをはてなブックマークに追加

https://lists.linux-foundation.org/pipermail/ksummit-2009-discuss/2009-April/000002.html

なんか第一候補が発表されたらしい。
日本人っぽいのを適当にピックアップ

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>

(あ、節子、マグナスは日本人ちゃうで)
海外さんや、原田さんは残念っぽい。

富士通多いな。でも、ここから半分に減るので、ちょっと生き残れそうにない。

関連記事
linux | 【2009-04-20(Mon) 10:34:54】 | Trackback:(0) | Comments:(3)

ドイツのォォォォ、科学力はァァァァァ このエントリーをはてなブックマークに追加

http://www.afpbb.com/article/environment-science-it/science-technology/2592664/4029268

でとりあげられてるコンテストの優勝作品がマジキチらしい(ほめ言葉)



こんだけぐりぐり動いて4KB(4Mちゃうで)らしい。

http://www.pouet.net/prod.php?which=52938 からダウンロードできるらしい

関連記事
雑談 | 【2009-04-18(Sat) 18:07:59】 | Trackback:(0) | Comments:(0)

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

元はUlrichのBlog
時期的に考えると、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バージョンと通常バージョンのどちらをルックアップするか変えるよ



関連記事
linux | 【2009-04-18(Sat) 16:42:29】 | Trackback:(0) | Comments:(2)

Redhatプロダクトではext3のデフォルトモードをwritebackに変えないよ このエントリーをはてなブックマークに追加

http://valhenson.livejournal.com/37921.html

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

というポストの人なので信頼できる情報なのではないかしら


関連記事
linux | 【2009-04-18(Sat) 16:03:28】 | Trackback:(0) | Comments:(2)

続々 sysfs の poll の件 このエントリーをはてなブックマークに追加

GregがLinusに今日送ったので2.6.30に間に合う。
メールサブジェクトが

[GIT PATCH] driver core patches for 2.6.31-rc2

と三ヶ月未来に生きているぜ状態だったので一瞬混乱したが


関連記事
linux | 【2009-04-18(Sat) 12:59:25】 | Trackback:(0) | Comments:(0)

[英語] Bob's your uncle このエントリーをはてなブックマークに追加

http://blog.goo.ne.jp/batchmongara/e/746b113e763278d9a017b3b417432448

「だいじょうぶ、問題ない、ほら簡単、楽勝だろう」 という意味らしい

例文:

>

>> -__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();



関連記事
英語 | 【2009-04-17(Fri) 21:58:30】 | Trackback:(0) | Comments:(0)

胃痛がひどい このエントリーをはてなブックマークに追加

これは本気で原因を探し出して、殴りにいかないといかんなー
明日、休日出勤決定やんけ。

関連記事
雑談 | 【2009-04-17(Fri) 12:10:25】 | Trackback:(0) | Comments:(0)

NTT OSSセンタについてちょっと調べてみた このエントリーをはてなブックマークに追加

https://www.oss.ecl.ntt.co.jp/ossc/oss/c_linux_2.html


■Linux Kernel 開発/改善への貢献
年度 Linux Kernel 採用数 Red Hat Bugzilla 報告数
2008年度 22件 7件
2007年度 24件 6件
2006年度 11件 3件

(2009/01/13時点NTT OSSセンタによる集計データに基づく)


どうもまともにOSSに取り組んでいる場所ではなさげ。コミュニティに普通に参画したら年間500件とかになるはず。ソースは自分の会社。
なんぼなんでも、能力が20倍の差はありえないから、上司の理解がないとしか思えん。

中の人がちょっとカワイソス


関連記事
linux | 【2009-04-17(Fri) 12:05:02】 | Trackback:(0) | Comments:(2)

マルチスレッドプログラムはforkしたらexecするまでの間はasync-signal-safe な関数しか呼んではいけない このエントリーをはてなブックマークに追加

http://cvs.m17n.org/~akr/diary/2009-04.html#a2009_04_15

このへんの資料みながら。
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 な操作しかしちゃだめってこった。


でも、実際問題として、世の中には規格を調べない人がいっぱいいるので・・・



関連記事
linux | 【2009-04-16(Thu) 20:58:04】 | Trackback:(0) | Comments:(0)

続 @ITのmeminfoの見方の説明が完全に間違っている件について このエントリーをはてなブックマークに追加

http://www.atmarkit.co.jp/flinux/rensai/tantei01/bangai01c.html

続く 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 を勧めるのもどうかと思う。


関連記事
linux | 【2009-04-16(Thu) 16:30:34】 | Trackback:(0) | Comments:(4)

@ITのmeminfoの見方の説明が完全に間違っている件について このエントリーをはてなブックマークに追加

http://www.atmarkit.co.jp/flinux/rensai/tantei01/bangai01c.html

 Activeはページキャッシュや無名ページ(注3)のうち、最近利用したり、まだストレージとの同期が取れていない「捨てられない」ページです。Inactiveは、同じくページキャッシュや無名ページのうち、最後にアクセスされてからある程度時間がたち、ストレージとの同期も完了していて、すぐに捨てられるページです。よって、/proc/meminfoの出力でいうところの MemFreeとInactiveを足すことで確実に利用可能なメモリ量を算出することができます。

(実際に利用可能なメモリ量)≒(MemFree+Inactive)

 この値を利用し、一定量を下回らないようにするのが、簡単・確実なメモリ利用率監視法といえます。



間違ってる。完全に。

たぶんNTT OSSセンタという所は顧客と直接取引がある部署ではないのではないかと推測。さすがにこんなデタラメを説明する所があるとは信じがたい。

まず、ActiveとInactiveの違いは、メモリ不足発生時にInactiveのほうが先に回収可能性チェックをされる。という意味しかない。
Inactiveにもダーティーページ(ストレージが同期がとれていないページ)やmlockされたページなど捨てられないページは大量に混じっている。
また、Inactiveをチェックして、回収したりActiveに入れなおしたりして減ったInactiveのページ数はActiveからInactiveに落とすことにより、補充されるので、Activeであることも何も保障してない。



関連記事
linux | 【2009-04-16(Thu) 16:24:14】 | Trackback:(0) | Comments:(2)

aio contextはforkで継承されません このエントリーをはてなブックマークに追加

なんか、io_setupで作ったカーネル内の構造体は継承されないのに、データ受け渡しようのリングバッファは継承さえる、かつ、man forkには何も書いてないという事で、

・リングバッファをmadvise(DONTFORK)しろ
・man forkに加筆しろ

と主張してみたが、どうやら通りそう。


関連記事
linux | 【2009-04-15(Wed) 09:15:48】 | Trackback:(0) | Comments:(0)

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

さっき、数分かけてHackしたdown_write_killable()が動かない。これなしでリリースするか

関連記事
linux | 【2009-04-14(Tue) 00:54:39】 | Trackback:(0) | Comments:(0)

Linux and FreeBSD POSIX mutexes and semaphores このエントリーをはてなブックマークに追加

http://www.ioremap.net/node/216

LinuxとFreeBSDでPOSIX mutexとsemaphoeのスループットを計測したよんというBlog.

・Linuxのmutex(futex)はFreeBSDより1.5倍くらい速いよ
・競合がないときは、なぜかsemaphoeが二倍速いけど意味不明
・まあどちらにしろ、全然スケールしないから、POSIX mutexはコンテンションがほとんどないように
 設計しないととんでもないことになるね



関連記事
linux | 【2009-04-13(Mon) 11:36:31】 | Trackback:(0) | Comments:(0)

最新のクロスコンパイラは毎週あっぷするよん このエントリーをはてなブックマークに追加

だってさ
めちゃんこ、いい人やんけ

On Fri, 2009-04-10 12:49:13 +0200, Sam Ravnborg  wrote:
> 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 | 【2009-04-13(Mon) 11:19:24】 | Trackback:(0) | Comments:(0)

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

本気で追加しようとしているから困る。そこはインプリ見直す所だろう。。

関連記事
linux | 【2009-04-11(Sat) 23:16:58】 | Trackback:(0) | Comments:(0)

Analog Deviceから開発用ボード送られてきた このエントリーをはてなブックマークに追加

これを使ってNOMMUもテストしてね♪
という意味らしい。

Blackfinなんて初めてみたよ。

関連記事
linux | 【2009-04-11(Sat) 14:52:50】 | Trackback:(0) | Comments:(0)

[linux-btrfs] Btrfs TODO このエントリーをはてなブックマークに追加

Josef Bacik が投稿したbtrfsのTODO(とど)リスト

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



関連記事
linux | 【2009-04-10(Fri) 09:29:24】 | Trackback:(0) | Comments:(0)
次のページ
  1. 無料アクセス解析