はじめに
現在のLinuxカーネルはメモリーホットプラグという，一般的にはなじみがない機能をサポートするようになっています。私は長い間その開発にかかわってきました。
コミュニティに参加する方法というのは，今ではノウハウ化が進み，「Linuxカーネル開発への参加方法」という文書も紹介されるようになりました。
しかし，私が活動をはじめた当時は，まだどうやって開発していけばよいのか勝手がわからず，四苦八苦することとなりました。これまでプロプラエタリなソフト開発しかしたことがないエンジニアにとって，コミュニティ開発というのはまったく開発スタイルの違う世界に飛び込むことだったからです。しかし，その苦労によって得られた経験は，その後の他の開発活動に活かされることになりました。ちょうど良い機会をいただいたので，そのときの苦労を振り返りたいと思います。
メモリーホットプラグをサポートしているハードウエアは，世の中にそんなにありません。そのためコミュニティの支持がなかなか得られず，カーネルにマージされるまでは困難を極めました。
しかし逆に言うと，メモリーホットプラグがカーネルにマージすることができたというのは，マイナーな機能であってもやり方次第でマージが可能であるという証明でもあります。ですから，カーネルになかなかマージされない機能やパッチというのは，使用する人が多いのかどうかということとは別に，何か他の問題を抱えているのかもしれません。そういう問題を抱えている方に，これを参考にしていただけると幸いです。
（お断り：以下の話はわかりやすくするため，前後関係など多少脚色が入っています。）
背景---そもそも，メモリーホットプラグって何？
最初に少しメモリーホットプラグの機能と背景を説明しましょう。
メモリーホットプラグと言っても，USBメモリースティックのようなデバイスを抜き差しするという意味ではありません。イメージ的には，マザーボード上に載っているDIMMをシステム運用中に抜き差しする…ということに近いものです。
こんなことをする理由の一つはメモリー故障時の交換です。99.999%以上のシステム稼働率を求められるようなシステムの場合，メモリーやCPUが壊れたからと言っても，簡単には停止できません。年間で停止時間5分以下を実現するのは，簡単なことではないのです。
クラスタリングをしていても，フェールオーバにかかる時間さえ惜しいという場合すらあります。少しでも停止時間を短くするために，メモリーエラーがECCによるエラー修正が可能な間に，故障したDIMMモジュールを交換してしまうのが理想なのです。
また，キャパシティオンデマンドという使い方も考えられます。大型のサーバー機では，論理的にシステムを２つ以上のマシンに区分けすることができるものがあります。
大きなシステムの場合，図1のように1つの大型サーバーを，役割別にシステムを論理分割して2つ（あるいはそれ以上）のサーバー（パーティション)にすることが行われていたりします。この場合，それぞれの区画でOSが別々に稼働します。
この図はある業務システムでの例ですが，この中のオンライン業務というのは，ATMなどのお金の振込み／引き出し処理を主な業務とします。夜間バッチというのは，水道料金の自動振込み処理など夜中に一括して実施するような処理を行います。
こういう分け方の場合，昼はATMの処理を行うオンライン処理に負荷がかかるので，そちらにメモリーを多く割り当てます。夜はオンラインの処理が必要になることはあまりありませんから，自動的にオンライン処理のシステムからメモリーをいただいて，夜間バッチのパーティションにメモリーを追加します。
なお，この場合，物理的にメモリーを切り離す必要はありません。どちらのパーティションにメモリーを割り当てるかは，ハード／ファームが論理的に設定していますから，それを切り替えるだけです。こうすることで，必要な資源を必要なだけ割りあてるシステムを実現するわけです。Linuxではまだ稼働例は聞いていませんが，他のOSでは既にこれと似たようなことを実施しているユーザーも現実に存在します。※1
最後に電力消費量の削減という用途もあります。電力消費を抑える目的で，メモリーを論理的に切り離して，少しでも電源消費を節約するというようなことも考えられています。
※1 もっとも最近は，ハード的にメモリーホットプラグをサポートしていない一般的なサーバーでも，VMwareやXenのような仮想化ソフトのおかげで，こういう運用が実施しやすくなりました。
