April 2009

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

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

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

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

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>

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

富士通多いな。でも、ここから半分に減るので、ちょっと生き残れそうにない。
このエントリーをはてなブックマークに追加

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

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



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

http://www.pouet.net/prod.php?which=52938 からダウンロードできるらしい
このエントリーをはてなブックマークに追加

元は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バージョンと通常バージョンのどちらをルックアップするか変えるよ
このエントリーをはてなブックマークに追加

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

というポストの人なので信頼できる情報なのではないかしら
このエントリーをはてなブックマークに追加

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

[GIT PATCH] driver core patches for 2.6.31-rc2

と三ヶ月未来に生きているぜ状態だったので一瞬混乱したが
このエントリーをはてなブックマークに追加

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();
このエントリーをはてなブックマークに追加

これは本気で原因を探し出して、殴りにいかないといかんなー
明日、休日出勤決定やんけ。
このエントリーをはてなブックマークに追加

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倍の差はありえないから、上司の理解がないとしか思えん。

中の人がちょっとカワイソス
このエントリーをはてなブックマークに追加

↑このページのトップヘ