従来のLinuxはread(2)やwrite(2)によるメモリアクセスは二回タッチでactiveリストへ移動だったのに、 mmapによるタッチは(pteのaccess bitが1bitしかない関係で）１回タッチでactiveリストになっていた。 そのため、現代的なマシンではmmapを使ってコピーすると逆に遅いという自体が発生していた。 以下のURL参照 http://d.hatena.ne.jp/kzk/20060513 んで、１年ぐらい前にmadviseしたときだけ、page activationを控えめにするパッチが入っていたのだが 今回2.6.34において、madviseなしでもused onceページはactiveリストに移動しないように論理が変更された。 と、定性的に説明するのも芸がないので、ベンチをとってみた。 測定ソフト --------------------------

ひさしぶりにプログラミングの話題でも。 現在のRubyのtrunkをx86_64上のFedora12でmake test-allすると8個ぐらいテストが失敗するのだが、その中の１つにこういうエラーがある 1) Failure: test_sin(DL::TestDL) [/home/kosaki/linux/ruby/test/dl/test_dl2.rb:95]: <1.0> expected but was <1.38523885234213e-309>. test/dl/test_dl2.rbというのが、なにをしているテストかというと、ようするに以下のようにdlモジュールを使ってlibmのsin関数を呼んでいるわけだ module DL class TestDL < TestBase # TODO: refactor test repetition def test_sin() pi

なんか、DreamCastの巻き添えを食らってandroidのコードが全削除食らったようだ。 何この面白展開 On Mon, Oct 05, 2009 at 04:21:35PM -0700, Randy Dunlap wrote: > On Mon, 5 Oct 2009 19:03:24 +1100 Stephen Rothwell wrote: > > > Hi all, > > > > Changes since 20091002: > > > drivers/staging/dream/gpio_axis.c:18:30: error: linux/gpio_event.h: No such file or directory Argh, I'm getting sick of the dream code. I'll sit down tomorrow and work it

最近、kosakiという人が「オレはLKMLでもっとも頻繁にOOMバグの解析を行っているデベロッパの一人である。オレが言うんだから間違いない。現在のOOMの表示と/proc/meminfoはフィールドが足りない」と真偽が定かではない主張をして、フィールドを大量に増やすパッチを、ねじ込んだ。 ちなみに、現在の /proc/meminfoはこんな感じ $ cat /proc/meminfo MemTotal: 6037184 kB MemFree: 1229820 kB Buffers: 252336 kB Cached: 3673464 kB SwapCached: 0 kB Active: 1463432 kB Inactive: 2772100 kB Active(anon): 315332 kB Inactive(anon): 16 kB Active(file): 1148100 k

http://lwn.net/Articles/343608/rss 新しいgccで、GPLv2のプログラムをコンパイルすると再配布不可能になるよ。という話。よく知られているように、gccはコンパイル時に（勝手に）libgccをリンクする。これは除算のサポート等が含まれている。うろ覚えだけどC++の例外の補助コード等もここ。 んで、勝手にリンクされる都合上、あんまりきつい制約に出来ないのでGPLなんだけど、特別免除としてプロプラなライセンスとリンクしてもOKということにしてあげるよ。ということになっている。 で、このGCC runtimeのライセンスが、gcc 4.4からGPLv3になった。で、プロプラなライセンスは従来の特赦条項で救われるのでOKだけど、GPLv2は再配布時にライセンス変更しちゃダメ条項があり、かつ、GPLv2とGPLv3はincompatibleなので、自動的にライセン

http://slashdot.jp/linux/article.pl?sid=09/07/22/0121226 この脆弱性であるが、Linuxにおいてはユーザプロセスが0番地にmmap()することが合法だったので ユーザ空間のデーモンなどにも大穴があいていた。 んで、そもそもなんで０番地mmapなんかする必要があるんだーーという議論になり、vm86では必要とか そんな議論に。 で、一時互換性重要派閥が勝利しかけたんだけど、Linus裁定により、特殊なpersonalityを持つプロセス以外０番地mmap()できなくなったはず。 うろ覚えで書いているから、まったく間違っているかもしれない。 まあ、ようするにgccの仮定がセキュリティ視点からはナンセンス極まりなかった。とそういうイージーな問題。 追記：なんか、Eric Parisがうだうだ言ってたので貼っとく。 ようするに、SELinuxを

ほぼT/O。 最近、LKML的義理人情の兼ね合いでFreeBSDをインスコしたのだけれど、なぜか/ パーティションのみSoftUpdate がOFFがインストーラのデフォルトの模様 OFFにするメリットが思いつかないので、誰か教えてください。 ところで、SoftUpdateって、NCQとかが、OSの知らないところで、I/Oの順番入れ替えたらアウトのような気がするが、I/O barrier の実装ってどうなってんの？

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

革命の日々！ Home ＞ 草なぎ君が逮捕されたらしい プロフィール Author:kosaki 連絡先はコチラ ブログ検索 最近の記事 引っ越しました (12/30) THPの記事にちょっと追記した (09/10) Linuxカーネルの「TCP_TIMEWAIT_LEN」変更は無意味？ の件について (09/09) transparent hugepage considered harmful (09/02) sosreportで OpenStackのログ (07/20) robocopy の使い方 (12/12) Windows 再インストールした (11/20) RHELのO_SYNCって面白い事になってるんだなあという話 (10/21) RHEL7でスクリーンセーバー無効化 (09/03) commit 直前にChangeLogの日付を変更する (08/15) 最近のコメント てつ

元は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) の２つをサポートするべき。gccトリックによってCでこれを実現したよ。 ・C++ 201x support デストラクタを呼ばない quick_exit() とそれ用のat_exit()の変種、at_quick_exit()が追加されたので実装した

http://www.atmarkit.co.jp/flinux/rensai/tantei01/bangai01c.html Activeはページキャッシュや無名ページ（注3）のうち、最近利用したり、まだストレージとの同期が取れていない「捨てられない」ページです。Inactiveは、同じくページキャッシュや無名ページのうち、最後にアクセスされてからある程度時間がたち、ストレージとの同期も完了していて、すぐに捨てられるページです。よって、/proc/meminfoの出力でいうところの MemFreeとInactiveを足すことで確実に利用可能なメモリ量を算出することができます。 （実際に利用可能なメモリ量）≒（MemFree＋Inactive） この値を利用し、一定量を下回らないようにするのが、簡単・確実なメモリ利用率監視法といえます。 間違ってる。完全に。 たぶんNTT OSSセンタとい

x86には様々なNOPがあり、Intel® 64 and IA-32 Architectures Software Developer’s Manual に記載のあるものだけでも1byte長から9byte長までの種類がある。 これにprefix等の選択肢を考えると、まさに無限に広がる大宇宙。といった感じの可能性の広さである。 で、LKML内ではNOPの種類によって速度が変わることが広く知られていて、時折どのNOPを使うのがよいかが熱い議論になる。 特に近年は自己書き換えコードの都合で最速5byte NOP議論が熱い（long jumpが5byteだからね）。 まあ、5byte NOPと3byte NOP + 2byte NOP（とprefix NOP）のどれが速いか、なんて議論は、自転車置き場理論によって無駄にスレッドがのびていくので見ていて楽しい（ほんとか？） で、最近話題になったのはl

404 Blog Not Found さんがトラックバックくれてるみたいだ。 すばらしいまとめ記事をありがとうございます。 せっかくなのでお礼がてら、トラバのトラバをば ITProのチューニング記事(noatime付加)を検証してみた - 科学と非科学の迷宮 1. 電源投入してからGUIログイン画面が表示されるまでの時間を測定する。 2. 「# time find /usr/ -name linux」を実行し、findの実行時間を測定する。 1.はとにかく、2.では検証になりません。 基本的な「atimeはいつ更新されるのか」が誤解されているためです。 atimeは、データを読み出した時に更新される → メタデータを読んでも更新されない あー、これは２つ目の段落単体では正しいけれども、１つ目の段落の否定にはならないんだな。 どういうことかというと % stat . File: `.' Si

http://itpro.nikkeibp.co.jp/article/COLUMN/20080528/304432/ あまりに酷いのでdisる記事を書こうかと思ったら、末尾に小さく 出典：日経Linux 2002年4月号　45ページより （記事は執筆時の情報に基づいており，現在では異なる場合があります） と書いてあった。６年前の記事かよ！！ 古い内容が多いので、よい子は信用しないでね。

どうもあまり有名ではないらしいので、ここで書いてみる。 http://mkosaki.blog46.fc2.com/blog-entry-241.html で書いた事とほぼ同じだけれど。 Linuxにおいて、CPU負荷を測定するベンチマークでは以下の環境変数を設定すると往々にして性能があがる。 % setenv MALLOC_TRIM_THRESHOLD_ -1 % setenv MALLOC_MMAP_MAX_ 0 MALLOC_TRIM_THRESHOLD_ はOSに未使用になったメモリを返却する契機をあらわしていて、－１は決して返却しない事を表す。 MALLOC_MMAP_MAX_ は最大mmap数で０は決してmmapせず、どんなに大きなメモリでもbrkを使ってメモリを取る事を意味する。 で、性能に効くのは（たいてい）MALLOC_MMAP_MAX_のほう。 glibcはアンチフラグ

So long, and thanks for all the fish. SDスケジューラで有名なCon Kolivasの引退メッセージである。 素晴らしい。 ちなみに、日本語訳は「さようなら、いままで魚をありがとう」らしい。 そのfishは魚ちゃうやろーーーー と思っていたら、本人のページにも、そう書いてある。 すばらしい。 本人が魚と主張するなら仕方ないよな。 なんで引退メッセージを日本語で書こうと思い立ったのかはさっぱり分からんが（＾_＾；

しばらく、特殊なスレッド並列プログラムで（のみ）、プログラムが途中でSIGILLで死んでしまうという現象に悩まされていたのだが、 よくよく調べた結果、Linuxカーネルのキャッシュ管理がバグっているという結論に。 オレ様ＧＪ！ と書くと分けわからんので、以下詳細。 まず、Linuxのキャッシュ管理においてIA64アーキは特別な扱いを受けている。 普通のCPU: flush_icache_page(): i-cache をパージ lazy_mmu_prot_update(): NOP IA64: flush_icache_page(): NOP lazy_mmu_prot_update(): i-cache をパージ となっているので、lazy_mmu_prot_update()の呼び方を間違えると見事IA64でしか再現しないバグの出来上がりである。 で、カーネルいじってる連中でも忘れがちで

スラドってたまに役に立つ発言あるよな めも http://slashdot.jp/comments.pl?sid=364575&cid=1172213 http://journal.mycom.co.jp/articles/2006/05/15/bsd4/ [mycom.co.jp] http://www.bsdcan.org/2006/papers/jemalloc.pdf [bsdcan.org] http://people.freebsd.org/~jasone/jemalloc/bsdcan2006/jemalloc.pdf [freebsd.org]

諸卿もご存知の通り、Linuxのメモリアロケーションはmalloc(), mmap()した段階ではメモリ割付をせず、最初にメモリにアクセスしたときに行うという俗に「first touch」と呼ばれるアロケーションポリシーを採用している。 さて、んでは、このmmap()したけどまだ実際にはメモリ割付されているないアドレスにたいしてmlock()したらどうなるか。 というと、この時点でメモリ割付が走る。 走るのはいいんだが、これがまたベラボーに遅い。 別にLinuxカーネルのアルゴリズムが悪いわけではなくて、メモリ割付をする＝そのページを０クリアするという事なので、DRAMのアクセス速度が超えられない壁となって立ちはだかるわけだ。 じゃあ、どのくらい時間がかかるか計算してみよう。 まず、DRAMをDDR2 PC5300と仮定しよう。イマドキ、こんなもんよね。 これでアクセス速度理論値 5300

前回の記事について、説明が不足していたようで、404 Blog Not Found様からmultipart/form-data を忘れている とお叱りを頂いてしまいました。 えっと、誤解です。 multipart/form-dataを使っても状況はまったく変わらないことが分かったので説明を省略しただけです。 誤解をとくために前回の調査結果を簡単にまとめさせてください。 ・Webの世界でEUCといったらCP51932がデファクトスタンダードである ・これは本来のEUCから補助漢字をなくして、かわりにWindows機種依存文字を 追加したものである。 ・しかし、FirefoxだけはCP51932+補助漢字という独自拡張EUCを採用している。 ・これはURL Encoding の％エスケープを解いたあとのデータが補助漢字に ついて生EUCとするか、数値文字参照とするか、という違いとして現れてくる