2014年1月14日火曜日

kworkerのCPU過負荷

デスクトップを録画中にCPU90%以上の高負荷に見舞われた。数分間ディスクアクセスが続きその間はキーボードもマウスも受け付けない。LVMで2台目のHDをくっつけた数日後のことだったのでパフォーマンスが下がったのかと思っていたのだが、単なるディスク書き込みならI/Oをすべて奪い取るようなことはない。いつこれがはじまったのか記憶は曖昧だがカーネル3.8.0-33からだったかもしれない。

4コア中の1個目のコアのみに負荷がかかっているので、起動しているいずれかのプロセスの1個の特定のスレッドだけがCPUを使い果たしているのではないかと考えた。

ところがプロセスリストを見ると [kworker] なるプロセスが12個ほど発生していて、普段はOS起動時にちらっと1個だけ存在する極めて控えめなやつのはずだったものが、ここに来てオラオラ邪魔だどけ的に振る舞い始めている。頭にカーネルのkバッジを掲げる官憲みたいなプロセスの正体はほとんど知らなかった。topやiotopを見てもどのプロセスが呼んでいるかはわからない。実体がわかる名前くらい書いてもらいたいものだが。


フォーラムで調べてみるとかなり前から観察されている現象らしい。というか2年前から未解決のままかよ。

要約すると:

http://askubuntu.com/questions/176565/why-does-kworker-cpu-usage-get-so-high

共通の症状は、CPUの動作は通常通りで1つめのCPUコアだけが高負荷になっているところ。たとえば3つあるプロセスのうち2つが kworker で1つは gonem-system-mo である(topコマンドリストに出てくる最初の2プロセス)。
kworker はカーネルが起動するスレッドのプレースホルダープロセスであり、これは実際にカーネルプロセスのほとんどを実行しているものである。割り込みやタイマー、I/Oなどの特定のケースで使われる。これらは典型的にプロセスを実行するシステムタイムの大部分を占めている。
これをシステムから安全に排除する方法はなく、KDEとは無関係である(プログラムがカーネルに要求するいくつかのシステムコールを除く)。


1. カーネルをディストリが配布する最新のものにアップデートする。
2. unameコマンドでカーネルのバージョンが2.36以上であることを確認する。バージョン2.36以降が重要で、このバージョン以降がカーネルのDRM_KMS_POLLINGを無効化できるためである。2.5カーネルではDRM_KMS_POLLINGを無効化できない。たぶん2.35のバグフィックスでパッチが当たったのかもしれない。
3. 新しいカーネルで再起動し以下のコマンドを実行する。 
sudo echo N>/sys/module/drm_kms_helper/parameters/poll 
これは強制的にシステムの負荷を軽減し通常の状態に戻す。このコマンドが有効なのはシステムが再起動されるまでである。再起動後に値はpoll=Yに戻ってしまう。この効果を維持したい場合は以下のコマンドを実行する。
echo "options drm_kms_helper poll=N">/etc/modprobe.d/local.conf
追記:カーネル3.8xから3.9-rc5では、i915チップでIRQの衝突が起こるかもしれない。またdrm pollパラメータは何らかの理由で無効にされる。この解決方法はもう使えないかもしれない。スキルがあるなら以下の内容を試してほしい:
1. カーネルを3.2x系にダウングレードする
2. /etc/rc.localに「echo N> /sys/module/drm_kms_helper/parameters/poll」を追記するか、「drm_kms_helper.poll=0」をgrubの起動パラメータに追加する。
これは単なる応急処置なので続けて解決策を探ってほしい。

最初のスレに /sys/firmware/acpi/interrupts/ の値が高いものをdisableしろと書いてあるのだがいずれも値はゼロのままで、ここには割込みらしきものが出ていない。

2つ目のスレの解決策は古いし3.8付近では無効らしいので理屈がわかっている場合のみ適用したほうがいい。
なかにはUSBモジュールがボトルネックだとか、カーネルがやっていることだからお前が心配することじゃないよみたいな殿様カキコがあったりするのだが、いくつかはdrm_kmsに言及している。

DRM(Direct Rendering Manager)はXアプリがサーバを介せずに直接アクセスする手段を提供するもので、特定のビデオチップのためのカーネルモジュールらしい。KMS(Kernel Module Settings)とはカーネルからモニタの解像度や色数を設定するもの。

うちの構成はNVIDIAプロプライエタリドライバなのでKMSは使われてないはずなのだがどこかで衝突してる可能性はある。


とりあえずカーネルとドライバをアップデートして、 grub2の起動オプションに に drm_kms_helper.poll=0 を追加して様子を見る。これが有効になったかどうかはdmesgには出てこない。

20140115: topの観察を続けていたらディスクアクセスが起こっている最中にupdatedb.mlocateが起動されている。簡単に言うとファイルのインデックスを作っているだけなのだが、cronで1日1回明け方にまわしているだけだと思っていたのだがな。なんらかの拍子に起動されることがあるのかと思ったのだがそういう説明はないっぽい。

20140117:DRM_KMSのpollを0にしてupdatedbを止めてから症状が出なくなったが原因が特定できない。ただのswapだった可能性もあるが今のカーネルは空きメモリをキャッシュに使うのでメモリの使用量からではスワップアウトかどうかが追えないのでなんともいえない。もしかすると最初に見たkworker群と後に見たupdatedbは関係ないのかもしれん。





2014年1月13日月曜日

Cyclesでボリュームマテリアルテスト その3

ボリュームシェーダーのコードが11日に2.69.8公式ツリーにマージされたようだ。レンダリングがかなり軽くなった。いくつか変更点がある。
  • レンダータブのアルゴリズムの選択がなくなりボリュームサンプリングのステップ値と上限の設定が追加された
  • 等方性ボリュームノードはボリューム拡散(Volume Scatter)とボリューム吸収(Volume Absorption)に別れた。引数gの名称は異方性に修正
  • blenderartistスレの11日のDingto氏の書き込みによるとワールドにおけるサーフェスのライトは見えなくなったかまたは無効になった。サンプル画像にあるようなスポットライトの表現はできなくなったので、もし必要なら大きめの立方体などを使ってボリュームを適用してくれとのこと

散光星雲

レンダー所要時間:3時間40分 1000サンプル

ガス部分のマテリアルノード

最初にイメージしていたものにかなり近づいてきた気がする。きれいに透過したい場合はやはりボリュームノードの密度にアルファ値を食わせるのがいいらしい。しかしこれが前回のようなガワだけでなくボリューム内部まで正しく点描されているかどうかは不明だが、カメラを雲に突っ込むようなアニメーションにするのでないかぎり目的は果たせていると思う。

星雲のうち白い部分は本当は黄色にしたかったのだがなぜか緑が混じってしまい、ボロノイテクスチャの拡大縮小値を下げてしのいだ。白い部分は実はボロノイ模様の円と円の隙間の部分になっている。
上のカラーランプはガス全体を左から右にグラデーションをかけているもので、下のカラーランプで色分けをしている。

右下の千切れている部分は単にオブジェクトに潰れたICO球を追加しただけのもの。これをいくつか点在させればひつじ雲のようなものも作れるかもしれない。しかしながら、本来なら密度係数だけで、たとえば立方体オブジェクトの中にいくつもの雲の形を表現できるのがボリュームの機能なのだが、たぶんそれをやるとメモリを大量に消費するかもしれない。
その2で紹介したWoodcockの論文には、ボリュームを仮想パーティクルのように扱う手法を提唱していたので、オブジェクト内部の任意の座標に置かれた点の集まりをいかに軽量に扱えるかでアルゴリズムの良否がわかれるところだろう。

追記:スレでボリュームの密度にアルファ値を食わせるのは正しい使い方なのかと質問してみたのだが、特に指摘されなかったのでレンダー結果よければすべて良し的な。実際どういう使い方ができるかというのを検証するスレなので問題はないらしい。



2014年1月5日日曜日

トーマス・デンジーズ氏インタビュー記事

トーマス・デンジーズ氏 CyclesのOpen Shading Languageの開発者インタビュー

Dingtoリポジトリのコードを書いている本人のインタビュー記事。

原文:
BlenderDiplom.com Interview: Thomas Dinges on OSL in Cycles

http://blenderdiplom.com/en/interviews/540-interview-thomas-dinges-on-osl-in-cycles.html




2013年12月31日 ゴットフリート・ホフマン氏による執筆

トーマス・デンジーズ氏はBlenderの開発者であり、CyclesへのOpen Shading Language(以下OLS)の実装の推進を支えた一人である。さらにOpenShading.comのWebサイトの最新情報を担当し、関連情報のサポートやチュートリアルなどを紹介している。

このインタビューはFMX 2013( http://www.fmx.de/about/history/fmx-2013.html )で行われ、ドイツ語版のデジタルプロダクション誌で公開されたものである。

BlenderDiplom:トーマスさんはBlender CyclesレンダーエンジンへのOSLの実装に携わった開発者の一人だと伺っていますが、ご自身の経歴について簡単に教えてください。

トーマス:OSLは開発の早い段階からCyclesと関わっていました。2011年頃だったと思います。その頃OSLはすでに実装されていましたがまだ稼動可能状態にはありませんでした。Cyclesのメインの開発者であるブレヒト・ファン・ロンメル氏がCyclesを設計するときにOpen Shading Languageを拡張して使っていました。OSLはCyclesの開発プロセスで重要な要素でした。今でもその名前とツール類、それからワークフローを見ることができます。OSLは予定していた2つのシェーディングエンジンのうちのひとつでしたが、残念ながらそのときにはまだ動いていませんでした。

CyclesはCPUとGPUの両方でレンダーできるよう意図されていたため、OSLはCPUレンダリングのみで動き、ブレヒト氏が設計した2つ目のシェーディングエンジンはGPUで動いていました。この2つ目のエンジンはCyclesを開発しているときに皆の注目を集めましたが、それはOSLのプロジェクトがちょうど停滞しようとしていた矢先のことでした。

2012年の夏にOSLは稼働可能な状態になりました。それは私が若干のソースコードを読み小さな変更といくつかのデバグが施されたときでしたが、私は2011年時点のシェーダーシステムのすべての変更点をOSLに移植しなければなりませんでした。ルーカス・トン氏と共同作業し実行可能なプロタイプの公開にこぎつけました。

そのときにはすでにトン氏の設計したスクリプトノードが実装されていました。そこでようやくOSLシェーダースクリプトをCyclesで使うことができるようになったのです。

BlenderDiplom:話に聞いていたところではBlenderは2011年と2012年にいくつかのOSLに対応して使えるようになるとのことでしたが、2013年になってもBlenderは依然としてOSLシェーディング市場の独占状態にあります。ほかのエンジンはなぜOSLの採用に手をこまねいているのでしょうか?

トーマス:主な理由は利用可能なOSLが2012年以前にはまだ公開プロジェクトにはなかったからだと思います。「メン・イン・ブラック3」とか「ホテルトランシルバニア」とか「アメイジングスパイダーマン」などが公開され、これらはそれぞれ単独でOSLシェーディングが実際に使われた最初の映画です。それまでOSLはあまり知られていませんでした。

SONYイメージワークスで使われていることが知られていましたが、ほとんどの人はOSLの導入は時期尚早と考え、それで映像を作ることに懐疑的でした。今ではV-RayがOSLを実装する予定との情報があり、FMX 2013でそれが確認されました。

残念ながらそのネタはまだ守秘義務があるので詳細については公式に発表されるまで数週間ばかり待たなければいけません。

BlnderDiplom:それでBlender CyclesはOSLによるパストレーシングエンジンなわけですね。すでにたくさんのスクリプトが書かれたと聞きました。これらのスクリプトはほかのレンダリングエンジンのユーザーにも使えるリソースになるでしょうか?

トーマス:完全に再利用できると思います。それがシェーダー言語が設計された基本概念ですから。ほかのエンジンはおよそRenderman(訳注:ピクサースタジオのシェーダー言語)互換なのでシェーダーを変えても簡単に使えると思います。

ただしOSLの仕様ではない部分、BRDFやシェーダーなどは異なりますが、これらの部分はシンプルな関数呼び出しなのでシェーダー内部でそれを修正することは簡単にできると思います。

たとえばユーザーがプロシージャルテクスチャが実装されているあるシェーダーを使っているとして、ディフューズシェーダーを出力しようとしたら、ほかのエンジン名に名前を変更するだけです。

今のところはまだスクリプトはすべてのOSL対応レンダーエンジンをサポートできているわけではないですが。

BlenderDiplom:つまり再利用が可能で、また将来的にはBlender Cyclesのために書かれたスクリプトも他のレンダーエンジンのユーザーにも使えるというわけですね。

ところでOSLのWebサイトを運営なさっていますが現在のところCyclesでのOSLの使い方のみに限定されているようですが、ほかのレンダリングエンジンについても扱う予定でしょうか?

トーマス:もちろんです!

今のところOpenShading.comはCyclesに注視していますが、それは一般に公開されているレンダーエンジンで唯一のものだからです。

でもほかのエンジンがリリースされたらその情報も追加していきたいと考えています。V-RayなどがOSLをサポートするようになり、たくさんの実用的なOSLスクリプトを集めてユーザーが使えるように便宜を図ることは非常に価値があることだと思います。


訳注:おっさんかと思ってたら若いわ(´・ω・`)