ブログトップ 記事一覧 ログイン 無料ブログ開設

Simple is Beautiful このページをアンテナに追加 RSSフィード Twitter

2005 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2011 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2012 | 01 | 02 | 04 | 05 | 07 |
2013 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 09 | 10 | 12 |
2014 | 01 | 02 | 03 | 04 | 07 | 08 | 09 | 11 | 12 |
2015 | 01 | 02 | 04 | 05 | 06 | 12 |
2016 | 01 | 11 | 12 |
2017 | 03 | 04 | 05 | 06 |

2010/09/27 (月)

[]kindle購入ドタバタ劇

kindle購入。グラファイトカラー、3G+WiFiモデル。

驚愕なのは、この出荷から届くまでの時間。わずか3日。太平洋を横断してきているとはとても思えない驚愕のスピード。

f:id:takaochan:20100926065915p:image

シンプルな包装で届く。バーコードがオシャレな以外は飾りっ気は一切なし。

f:id:takaochan:20100913224317j:image

f:id:takaochan:20100924104421j:image

もうこの包装をあければ、すぐにkindleが入っている。下には簡単な説明書、さらにその下にはmicro USBの給電データ同期用のケーブル。ちょっと長い…。

f:id:takaochan:20100913224344j:image

f:id:takaochan:20100913224356j:image

f:id:takaochan:20100913224405j:image

噂のE-inkは、実際に見ると液晶モニターとは全く違う質感。印刷されている様というか、モニター部分にインクを使って書かれている様に見える。たしかにE-inkだ。みんなやっているけど、シートをめくっていてこれがシートに印刷されているのではなく、モニターに表示されているのだという事実を楽しむ。うーん、モノクロだけど綺麗。

f:id:takaochan:20100913224419j:image

f:id:takaochan:20100913224428j:image

…さて、楽しもう!ということだったのだけれども、使い始めて暫くしてモニター上部が悲しいことに…。木がない…。上半分がホワイトアウトしてまったく表示されない状態に…。

f:id:takaochan:20100918131732j:image

ここからが大変。現在kindleAmazon.co.jpではなくAmazon.comからの購入となるので、当然ながら交換依頼はAmazon.comで処理する必要がある。まずはAmazon.comのウェブサイトで交換申請処理。

Item Description: Kindle 3G Wireless Reading Device, Free 3G + Wi-Fi, 6" Display, Graphite, 3G Works Globally - Latest Generation

Quantity: 1

Reason for return: Damaged during shipping

Comments: The upper half of the screen is not displayed.

すると、Kindle Supportから「詳しく知りたいから電話してね」という旨が書かれたメールが来るので、Amazon.comのウェブサイトから自分の電話番号を入力するとものの数秒で向こうから電話がかかってくる。うーん、凄い。訛りの強い英語がイヤだったら夜にかける方がよいという情報があったので、夜10時過ぎに操作。

基本的に聞かれる内容は以下の通り。

    • どのような状況なのか
    • いつから問題が発生したのか
    • 圧力をかけるようなことはしなかったか
    • 本人確認
    • その他確認したい事項はあるか
    • 返送に関する確認事項

参考にした情報はこちらのBlogなど。この確認が終わると、交換品の発送手続きをとってくれる。あとは到着を待つだけ。現在はすでに在庫がある状態となっている模様で、手続きを行ってから1週間ぐらいで手元に届いた。素晴らしきかな、無事木が生えた(^_^;)。

f:id:takaochan:20100925012701j:image

現時点では、まだAmazon.co.jpでは電子書籍の販売は行われていないので、基本的にはPDFリーダー扱い*1

PDFデータは基本的にA4用紙向けに作られているので、Kindleの6インチモニターだとちょっと文字が小さい。

f:id:takaochan:20100925013004j:image

なんでVMwareの構成の上限PDFなのかは、私にもわかりません(^_^;)。細かい文字を拡大してみることもできますが、横向き表示にすれば、無理がない文字サイズで読むことができる。プレゼンPPTをPDF化したファイルは、元々のプレゼン資料のフォントサイズがそこそこの大きさならば普通に読める。モノクロだけど…。

f:id:takaochan:20100925012829j:image

Kindleの良いところは、電源を気にせずにじっくりと資料を読めるところ。というわけで、暫く使ってみてのレポートはまた追々。

*1青空文庫リーダーとしても使えるが、あまり古典には興味がないもので…

2010/09/22 (水)

[]VMware ESXにおけるメモリ管理(4) - メモリを割り当てるのは簡単だが、回収するのは難しい

VMware ESXにおけるメモリ管理』シリーズ

(1) - 序:他のリソースとの違いはなに?

(2) - 仮想化インフラにおけるメモリ管理って?

(3) - メモリに関する仮想化支援機能(Intel EPT/VPID, AMD RVI/Tagged TLB)

…の続きです。

物理マシンにOSが直接インストールされている場合、OSは全ての物理メモリを管理します。OSによってその管理方法は異なりますが、基本的には「割り当てた」メモリページを管理するか、「割り当てていない」(フリーの)メモリページを管理するかのいずれかの方法でメモリ管理を行います。いずれにしろ、OSはOS自身とOS上で実行される複数のアプリケーションのプロセスそれぞれに対してどの物理メモリページを割り当てているか把握していますし、プロセスは必要なメモリをOSに依頼して割り当ててもらい、そして「基本的には」不要となったメモリページはOSに返却します(返すように作ることが求められています)。

OSの場合と同様にHypervisorが仮想マシンに対するメモリ割り当てのタイミングを知ることは比較的簡単です。なぜなら、仮想マシンが始めてそのメモリページにアクセスしようとした際にまだ実際に割り当てが行われていなければページフォルトするからです。対して、不要となったタイミングを知ることは簡単ではありません。仮想化環境では複数の仮想マシンを並列で実行するわけですが、仮想マシン上に導入されるゲストOSはメモリページを仮想化レイヤーに対して返すようには作られていません。そもそも仮想化環境におけるゲストOSは「自分は物理メモリを管理している」と思って「仮想化環境によって割り当てられたメモリ空間」を管理していますので、「返す必要すらない」と思っているわけです。故に、仮想化環境では「OS側から返してもらう」ことはできませんので、「Hypervisor側から回収する」仕組みを用意する必要があります。ここが仮想化環境ならではのメモリ管理の難しさです*1

Hypervisorが管理する物理メモリ空間が潤沢にある場合は、別に「メモリの回収」が問題となることはありません。MicrosoftのHyper-VやCitrixのXenServerといった各社のHypervisorが最近までメモリのオーバーコミットを仕様としてできないようにしていた?*2理由はこの問題の難しさを示しているような気もします。

f:id:takaochan:20100922223845p:image

ではVMware ESXはどのような手法を用いてメモリの回収を行っているのでしょうか。ESXがメモリに関して持つ機能としては以下の4つがあります。

    1. 透過的ページ共有 (Transparent page sharing / TPS)
    2. バルーニング (Ballooning)
    3. ハイパーバイザースワッピング (Hypervisor swapping)
    4. メモリ圧縮 (Memory compression)

メモリ資源をいかに有効に活用していくか。そのためにはアクティブメモリを識別することによる「高いメモリ使用率」と、ホストが管理する物理メモリを必要としている仮想マシンに正確に割り当てることによる「高いVM統合率」を実現する必要があります。

次回は上述のESXが持つ4つのメモリ関連機能と、Dynamic Memoryという名称でWindows Server 2008 R2 SP1のHyper-Vから実装されるメモリ関連機能などについて、具体的な実装レベルを見ていきたいと思います。

*1:他にも仮想化環境ならではのメモリ管理の課題はあります。たとえばメモリを通じた仮想マシン間でのデータ漏洩はあってはならないことです。そのため、ESXでは仮想マシンに対してメモリページを割り当てる前に一度ゼロを書き込んでから割り当てを行います。

*2:Microsoft Hyper-VのDynamic Memoryがメモリオーバーコミットなのかどうかはさておき

2010/09/11 (土)

[]VMware ESXにおけるメモリ管理(3) - メモリに関する仮想化支援機能(Intel EPT/VPID, AMD RVI/Tagged TLB)

(1) - 序:他のリソースとの違いはなに?

(2) - 仮想化インフラにおけるメモリ管理って?

…の続きです。

Shadow Page Tableを使って「ゲストOS上のアプリケーション」のための仮想メモリ空間(Logical Page Numbers / LPNs)とHypervisorが管理する実メモリ空間(Machine Page Numbers / MPNs)のページ変換を直接的に紐づけている仕組みをハードウェア的に実装するとはどういうことでしょうか?

メモリ管理に関する仮想化支援機能には、IntelのEPT (Extended Page Table)と、AMDのRVI (Rapid Virtual Indexing)があります。

Intel EPTはその名が示すとおり、拡張されたページテーブルを実装することによりメモリのページテーブル変換の処理性能を事実上単一階層化する技術です。つまり、Intel EPTそのものはメモリにおけるページテーブル変換の性能を向上させるものではなく、ページテーブル変換が多層化することによるオーバーヘッドを(Shadow Page Tableのようなソフトウェア的な実装を用いることなく)発生させないようにする技術といえます。

Intelの仮想化支援機能であるIntel VTでは、リング階層とは全く別の仕組みであるVMX (Virtual Machine Extensions)によってVMX rootモードとVMX non-rootモードの2つのVMXモードを設けることによってハードウェアによる仮想化支援機能を実装しているわけですが、ゲストOSの実行モードであるVMX non-rootモードから特権命令を処理するためにVMX rootモードに移行する"VM exit"処理と、逆にVMM (Virtual Machine Monitor)による特権命令の処理が完了しVMX non-rootモードに戻る"VM entry"処理のそれぞれにおける「移行処理」にかかるオーバーヘッドは必ずしも小さくはありませんでした。

f:id:takaochan:20100905235149p:image

CPUの発展に伴い移行処理に要するオーバーヘッドは次第に改善されていき、Intel EPTを用いない理由はなくなりましたが、VMware ESXがIntel EPTに対応したのはそもそもがESX4.0からとなります。逆説的ではありますが、Intel EPTはメモリにおけるページテーブル変換時にVM exit処理が「なるべく実行されないように」するための実装ともいえます。

f:id:takaochan:20100907233440p:image

CPU世代ごとに、ESX4.0がEPTを用いるのか、それともShadow Page Table (SPT)を用いるのかについてはVMwareのウェブサイトhttp://communities.vmware.com/docs/DOC-9882にまとめられています。

f:id:takaochan:20100905235150p:image

この表にもあるとおり、EPTが積極的に使われるようになるのはCore-i7(Nehalem)以降のCPUが搭載されている場合のみとなります。

対するAMD RVIはIntel EPTに先駆けてESX3.5からサポートされていました。

f:id:takaochan:20100905235151p:image

基本的にはAMD RVIもIntel EPTとやっていることは同じで、メモリのページテーブル変換をハードウェアチップ回路で処理してしまう仕組みとなっています。

ここで示したように、ハードウェアによる仮想化支援機能を用いることが必ずしも処理性能を向上させるとは限らないわけですが、SPTとEPT/RVIを柔軟に使い分けられることもVMware ESXが他の仮想化ソフトウェアよりも優れている点の1つといえるかとは思います。

もう1つ、IntelAMDの双方が用意しているメモリに関するハードウェア支援実装がTLB (Translation Look-aside Buffer)の最適化に関する技術です。IntelはVPID (Virtual Processor ID)、AMDはTagged TLBと命名しています。TLBは前回Wikipediaへのリンクによって説明をしませんでしたが、要はCPUにおけるメモリページテーブルの変換バッファキャッシュです。TLBがあることによってOSは非常に高速なページテーブル変換を実現しています。仮想化環境においてTLBが問題になるのは、仮想マシンにおけるメモリページテーブルとHypervisorにおけるメモリページテーブルがそれぞれ異なるため、たとえばIntelの場合であれば、VMXモードの変移に伴ってTLBがフラッシュされてしまうことにあります。頻繁に発生するVMXモード変移のたびにTLBがフラッシュされてしまっていてはメモリ性能が大幅に低下してしまいます。

Intel VPIDはIDによって管理される複数のTLBを実装することによりこの問題に対応しています。Hypervisorが0番のIDを持つTLBを、各仮想マシンがそれ以外のIDのTLBを使用し、VMX non-rootモードでは各仮想マシンのTLBを、VMX rootモードではHypervisorのTLBを使うことによってTLBが都度フラッシュされてしまうことを抑止しています*1

f:id:takaochan:20100907233441p:image

AMD Tagged TLBもやっていることはおおよそ同じ。こちらは複数用意したTLBに対してタグをつけて仮想マシンとの紐付けを管理し、仮想マシン毎に紐づけられたTLBを使うことでTLBフラッシュを防ぐ仕組みとなっています。

今回はちょっとハードウェアよりの話だったので自分自身、書いていてちょっと難しかったです。次回は改めてVMware ESXの話に戻り、ESXホストがどのような仕組みでメモリを効率的に使うのか、一度割り当てたメモリをどのように「回収」しているのかなどの話に進みたいと思います。

*1:必要に応じてHypervisorは仮想マシン用のTLBを「意図的に」フラッシュすることも可能