4月版　Linus（と筆者）を嘆かせたanon_vma騒ぎ

小崎資広
2010/5/18

　こんにちは。本文で紹介するanon_vma騒ぎに巻き込まれまくって、ゴールデンウイークが丸ごとつぶれてしまってションボリな筆者です。いったいLKMLでどんなことがあったのでしょうか。それではどうぞ。

アダプティブMutexの最適解は？

　Darren Hartは「RFC: Ideal Adaptive Spinning Conditions」と題した興味深い投稿をポストしました。この提案はFUTEX_LOCKおよびFUTEX_LOCK_ADAPTIVEという新しいfutex操作を導入することにより、ユーザーランドスピンロック問題を解決することを目指しています。

　ユーザーランドスピンロック問題とは、昨年のkernel summit以降、盛んに議論されるようになったトピックです。現在、PostgreSQLなど一部のユーザーランドアプリケーションが、glibcのpthread_mutexの代わりに独自実装のスピンロックを使い続けているため、スピンロックと相性が悪いスケジューラの最適化が導入できず、結果としてスケーラビリティ向上を阻んでいるという問題です。

　従来のglibcのアダプティブMutexは、「最初のN回はスピンして獲得を試みるが、それ以降はブロックして待つ」という論理になっています。ロック所有スレッドがタイムスライスを使い果たしてCPU待ちをしていた場合、このスピンがロック所有スレッドの走行再開を遅らせてしまい、余計に遅くしてしまうことがありました。

　それに加え、ユーザーランドspin lockの実装にはしばしばsched_yield()が併用されるのですが、sched_yield()はカーネル内のコードのちょっとした変更により大きく挙動を変えてしまう性質があります。これも、カーネル・アプリケーション双方の保守性の観点から望ましくありませんでした。

　そのため、このパッチは現在カーネル内Mutexが行っているように、「ロック所有スレッドがCPU走行中ならスピンして待つが、そうでない場合はブロックする」という操作をfutexに追加しています。これがFUTEX_LOCK_ADAPTIVEです。また、スピンが望ましくないアプリケーション向けに、常にブロックするFUTEX_LOCKも同時に追加されています。

　Rik van Rielは、この提案にとても好意的な反応を示し、「普通の環境では意義が薄くても、仮想化環境では大きな意味がある」と発言しました。それまでの挙動では、ロック所有スレッドが動いているVCPUがハイパーバイザによってプリエンプトされ、長時間止まってしまうかもしれないからです。

　またPeter Zijlstraは「ユーザーランドスピンロックはevilだよ。そもそも使うべきじゃないんだ」と続けます。

　これに対してAvi Kivityは「スピンはユーザーランドで行った方がよい」と指摘しました。

　Darrenは「おいおい、それができれば苦労しないよ。ユーザーランドからロック所有スレッドの状態を知ることができるはずないじゃないか」と反論しますが、Aviはたたみかけるように「スレッドローカルストレージにフラグを立てておいて、カーネルが後からそこをチェックするってのはどう？」と提案します。続けて、「現状ではスピンが最速だというデータになってる。われわれがnon-evilなalternativeを提案しない限り、彼らはスピンロックを使い続けるよ。速度は重要だよ」と力説します。

　それに応じるようにAlan Coxは「non swappableなページを用意して以下のようなコードをユーザーランドで動かせばいいんじゃない？」と提案しました。

runaddr = find_run_flag(lock);         do {                 while(*runaddr == RUNNING) {                         if (trylock(lock))                                 return WHOOPEE;                         cpu relax                 }                         yield (_on(thread));         } while(*runaddr != DEAD);

　これに応じてThomas Gleixnerは、「yield_to_target()みたいなシステムコールを追加しないとね。引数のスレッドがrunning状態じゃなければちゃんと寝てくれるようなヤツをね」と答えます。

　Ulrich Drepperは「基本アイデアはいいと思うけど、事前にスレッド数なんて分からないのに、効率的に実装できるかな？」と疑問を挟みます。Alanは「4096スレッドにつき1ページ用意するだけだろう。大したことないさ」と主張しますが、Ulrichは「大問題だよ。キャッシュラインを64bitとして各キャッシュラインを64スレッドで競合させることになる」とすかさず返答。「4096/64＝64スレッドが1ページに載せられる限界だね。これでもたいていは全スレッドが1ページに載ると思うよ」と説明しました。

　この話は結局決着はつかず、「方向性としてはいいと思うが、ちゃんと性能が出る実装ができてから再審議」というステータスになったようです。今後が楽しみですね。

3月版へ

1/2

Index Linux Kernel Watch　4月版 　Linus（と筆者）を嘆かせたanon_vma騒ぎ

Page 1 　アダプティブMutexの最適解は？ 　 Page 2 　rmapスケーラビリティパッチとその混乱

連載 Linux Kernel Watch

---

Linux Squareフォーラム Linuxカーネル関連記事

	連載：Linux Kernel Watch（連載中） Linuxカーネル開発の現場ではさまざまな提案や議論が交わされています。その中からいくつかのトピックをピックアップしてお伝えします
	連載：Linuxファイルシステム技術解説 ファイルシステムにはそれぞれ特性がある。本連載では、基礎技術から各ファイルシステムの特徴、パフォーマンスを検証する
	特集：全貌を現したLinuxカーネル2.6［第1章］ エンタープライズ向けに刷新されたカーネル・コア ついに全貌が明らかになったカーネル2.6。6月に正式リリースされる予定の次期安定版カーネルの改良点や新機能を詳しく解説する
	特集：/procによるLinuxチューニング［前編］ /procで理解するOSの状態 Linuxの状態確認や挙動の変更で重要なのが/procファイルシステムである。/procの概念や/procを利用したOSの状態確認方法を解説する
	特集：仮想OS「User Mode Linux」活用法 Linux上で仮想的なLinuxを動かすUMLの仕組みからインストール／管理方法やIPv6などに対応させるカーネル構築までを徹底解説
	Linuxのカーネルメンテナは柔軟なシステム カーネルメンテナが語るコミュニティとIA-64 Linux IA-64 LinuxのカーネルメンテナであるBjorn Helgaas氏。同氏にLinuxカーネルの開発体制などについて伺った
	more

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）