JP2012123762A - 情報処理装置及び情報処理方法 - Google Patents
情報処理装置及び情報処理方法 Download PDFInfo
- Publication number
- JP2012123762A JP2012123762A JP2010276377A JP2010276377A JP2012123762A JP 2012123762 A JP2012123762 A JP 2012123762A JP 2010276377 A JP2010276377 A JP 2010276377A JP 2010276377 A JP2010276377 A JP 2010276377A JP 2012123762 A JP2012123762 A JP 2012123762A
- Authority
- JP
- Japan
- Prior art keywords
- code
- information processing
- execution history
- processing apparatus
- time
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Stored Programmes (AREA)
Abstract
【課題】起動時にロードするOSイメージサイズを抑制する事で起動高速化を実現しながらも、その後の実行スピードも極力低下させない仕組みを実現する。
【解決手段】ページフォルトを契機にしたデマンドページング機構22によるデマンドページング時に、OSコードの実行履歴23を収集し、収集したOSコードの実行履歴23を外部記憶装置13に保存し、システムの再起動時にboot25が参照でき、再起動時には、boot25が保存されたOSコードの実行履歴23を元に、前回起動時に実行した実績のあるOSコードのみをメインメモリ12にロードする。
【選択図】図2
【解決手段】ページフォルトを契機にしたデマンドページング機構22によるデマンドページング時に、OSコードの実行履歴23を収集し、収集したOSコードの実行履歴23を外部記憶装置13に保存し、システムの再起動時にboot25が参照でき、再起動時には、boot25が保存されたOSコードの実行履歴23を元に、前回起動時に実行した実績のあるOSコードのみをメインメモリ12にロードする。
【選択図】図2
Description
本発明は、デマンドページング機構を利用した情報処理装置及び情報処理方法に関するものである。
従来、システムの起動時にはブートストラッププログラム(以降「boot」と表記)が、オペレーティングシステム(以降「OS」と表記)全体を不揮発メモリ又は外部記憶装置から、RAMにコピーした後、OSのエントリコードにJUMPして起動していた。この手法は、単純かつ明快であるので、多くのシステムで採用されている。
ところが、近年、OSの機能拡張によりそのコードサイズが大きくなってきた。特に、UNIX(登録商標)系のOSなどを使った場合、OSのサイズが数MBを超える事も有り、これを全てメモリに展開するのに時間がかかり、その結果、システムの起動スピードが低下する問題があった。
これに対処するため、圧縮OSイメージを使ったメモリ転送で高速化する手法や、RAMをバッテリで保持しておいて再展開を抑制する手法などが提案されて使われている。ところが、これらの手法は効果が低かったり、ハードウェアの支援が必要でコストがかかったりするため、必ずしも有効な解決策とはなっていない。
上記の様なOSコードの展開に時間がかかる問題は、OSのイメージサイズが巨大である事に起因する。つまり、起動時に展開するOSコードが十分小さければ、展開にかかる時間の問題は解決できる。
この点に目をつけた解決策として、上記特許文献1の技術がある。この特許文献1の技術では、OSの中で起動に必要な部分だけをまとめておき、これを先行してRAMに展開する。この状態でOSの起動を開始し、残りの部分は必要に応じてページフォルトを契機としたデマンドページング機構でダイナミックロードするというものである。このように、上記特許文献1の手法は、確かに起動時のRAMへの展開量を抑制する事が可能なので、有効な解決策である。ただし問題もある。OSの残りの大部分はRAM等に展開されていないので、その後のスループットがデマンドページングのオーバーヘッドにより低下してしまう。
本発明は、このような問題点に鑑みてなされたものであり、起動時にロードするOSイメージサイズを抑制する事で起動高速化を実現しながらも、その後の実行スピードも極力低下させない仕組みを実現することを目的とする。
本発明の情報処理装置は、デマンドページング機構を利用した情報処理装置であって、ページフォルトを契機にした前記デマンドページング機構によるデマンドページング時に、OSコードの実行履歴を収集する収集手段と、前記収集手段で収集したOSコードの実行履歴を外部記憶装置に保存し、システムの再起動時にブートストラッププログラムが参照できる参照手段と、前記再起動時には、前記ブートストラッププログラムが前記保存されたOSコードの実行履歴を元に、前回起動時に実行した実績のあるOSコードのみをメインメモリにロードするロード手段とを具備する。
また、本発明は、上述した情報処理装置による情報処理方法を含む。
また、本発明は、上述した情報処理装置による情報処理方法を含む。
本発明によれば、起動時にロードするOSイメージサイズを抑制する事で起動高速化を実現しながらも、その後の実行スピードも極力低下させない仕組みを実現することが可能となる。
以下に、図面を参照しながら、本発明を実施するための形態(実施形態)について説明する。
(第1の実施形態)
図1は、本発明の第1の実施形態に係る情報処理装置のシステム構成の一例を示すブロック図である。
図1は、本発明の第1の実施形態に係る情報処理装置のシステム構成の一例を示すブロック図である。
図1において、10は、本実施形態に係る情報処理装置である。
図1において、11は、CPUであり、情報処理装置10のほぼ全てを管理している。
図1において、12は、メインメモリであり、CPU11からアクセスすることが可能である。
図1において、11は、CPUであり、情報処理装置10のほぼ全てを管理している。
図1において、12は、メインメモリであり、CPU11からアクセスすることが可能である。
図1において、13は、外部記憶装置である。
図1において、14は、不揮発メモリである。この不揮発メモリ14は、一般にFLASHメモリであり、プログラムはここに格納されている。
情報処理装置10のシステム構成によっては、外部記憶装置13として、不揮発メモリ14を利用して、一時ファイルを格納する場合もある。
図1において、14は、不揮発メモリである。この不揮発メモリ14は、一般にFLASHメモリであり、プログラムはここに格納されている。
情報処理装置10のシステム構成によっては、外部記憶装置13として、不揮発メモリ14を利用して、一時ファイルを格納する場合もある。
図1において、15は、情報等を入力する入力インタフェース(入力I/F)である。
図1において、16は、情報等を出力する出力インタフェース(出力I/F)である。
図1において、16は、情報等を出力する出力インタフェース(出力I/F)である。
また、本実施形態では、以下の様なシステムを想定する事とする。
・OS全体のコードサイズ=4MB
・OSコアのサイズ=32KB
・1ページのサイズ=4KB
・OS全体のコードサイズ=4MB
・OSコアのサイズ=32KB
・1ページのサイズ=4KB
図2は、本発明の第1の実施形態を示し、図1のCPU11によって実行履歴を収集し、その実行履歴を利用する事で次の起動を高速化する流れの一例を示す模式図である。
図2において、21は、OSの中で最低限必要な機能だけを集めたコアコード(OSコア)である。このOSコア21は、システム起動時に必ずメモリに展開される必要がある。なぜなら、OSの実行位置の履歴を取るために、以下の様な機構を必要とするからである。
・デマンドページング機構(22)
・最低限の初期化コード
・最低限のデバイスドライバ
・デマンドページング機構(22)
・最低限の初期化コード
・最低限のデバイスドライバ
図2において、22は、OSコア21に含まれる、デマンドページング機構である。これは、ページフォルトを検出し、その履歴を記録後、未ロード部分のOSコードをメインメモリ12に展開する機能を持つ。
図2において、23は、実行履歴であり、デマンドページング機構22によって更新される。この実行履歴23は、OSコードの実行個所の情報として、次回起動時に不揮発メモリ14に格納されている、ブートストラッププログラムであるboot25によって参照される。
図2において、24は、OSイメージ本体である。ここには、OSコア21が含まれており、外部記憶装置13か不揮発メモリ14に保存されている。図2の例では、OSイメージ本体24は、外部記憶装置13に保存されている。
図2において、25は、bootであり、システムの起動時に最初に実行されるプログラムである。boot25は、実行履歴23の情報を元に、不揮発メモリ14か、又は、外部記憶装置13内のOSイメージ24から、OSコア21と前回実行したOSコードをメインメモリ12にコピー(展開)して起動する。
この様に起動された後、デマンドページング機構22は、再び、OSプログラムのどの部分が実行されたかを監視し、その結果を実行履歴23として書き出す。このサイクルによって、起動高速化を実現する。
図3は、本発明の第1の実施形態を示し、デマンドページング機構22で未ロードのOSコードを検出する過程の一例を示す模式図である。
実行履歴23にOSコア位置情報しか存在しない場合、boot25は、OSコア21だけをメインメモリ12に展開し、OSコア21のエントリアドレスにJUMPする。OSコア21は、boot25から起動されると最低限のシステム初期化を行うが、その初期化過程の中でページテーブル31を構築する。
今回の実施形態では、ページテーブル31のイメージは図3の様になる。つまり、OSコア21の32KBの領域に対応するページテーブル31(page0〜page7)の属性ビット32が1(有効)にセットされる。また、その他のOSの領域に対するページテーブル31(page8〜page1048575)の属性ビット32が0(無効)に設定される。
もし、実行履歴23にページ位置情報が存在した場合には、そのページはboot25によってメモリに展開済みであるので、そのページに対応するページテーブル31の属性ビットは1(有効)に初期化される。
この様に初期化された後、システムがスタートする。関数呼び出しやJUMP命令の実行によりOSの処理がOSコア21外に出る(図3の[1])と、それはページフォルトとしてCPU11に補足され、デマンドページング機構22に処理が移る(図3の[2])。
デマンドページング機構22は、ページフォルトを起こしたアドレスをCPU11から取得すると、その結果に基づき実行履歴23を更新する(図3の[3])。その後、外部記憶装置13にあるOSイメージ24本体から該当するOSコードの1ページをメインメモリ12に展開し、対応するページテーブル31の属性ビットを1(有効)に変更する。そして最後に、ページフォルトを起こしたアドレスから実行を再開させる(図3の[4])。
このサイクルによって、実際に実行したOSのコード位置を実行履歴23として記録していく。
図4は、本発明の第1の実施形態を示し、boot25が実行履歴23を参照してメインメモリ12に必要なOSイメージを展開する処理の一例を詳細に示す模式図である。
システムが起動すると、不揮発メモリ14にあるboot25に制御が移る。boot25は、外部記憶装置13又は不揮発メモリ14にある実行履歴23を参照する(図4の[1])。この実行履歴23にOSコア位置情報しかない場合には、OSコア21だけをメインメモリ12に展開し、エントリアドレスにJUMPする。実行履歴23にページ位置情報もある場合には、その情報を元にアクセスしたコード位置を算出し、OSイメージ24から該当するコードを含むページをメインメモリ12に展開する(図4の[2])。そしてこの処理を繰り返して、前回アクセスした全てのページを展開後、エントリアドレスにJUMPする(図4の[3])。
図5は、本発明の第1の実施形態を示し、boot25がOSイメージをメインメモリ12に展開する処理の一例を示すフローチャートである。以下、各処理について述べる。
まず、ステップS51において、CPU11は、実行履歴ファイルが存在するか否かを判断する。この判断の結果、実行履歴ファイルが存在しない場合には、OSコア位置情報やページ位置情報を得る事が出来ないので、本発明の起動高速化を適用する事は出来ない。よって、この場合には、ステップS58に進み、OSイメージ全体をメインメモリ12に展開後、OSエントリにJUMPして、図5のフローチャートの処理を終了する。
一方、ステップS51の判断の結果、実行履歴ファイルがある場合には、ステップS52以降に進み、本発明の起動高速化の処理を継続する。
ステップS52に進むと、CPU11は、実行履歴ファイルからOSコア21の位置情報を取得する。そして、CPU11は、OSイメージから該当する部分をメインメモリ12に展開する。
続いて、ステップS53において、CPU11は、実行履歴に、ページ位置情報がまだあるか否かを判断する。この判断の結果、全てのページ位置情報を処理するか、又はページ位置情報がまったく無い場合には、必要なOSコードをメインメモリ12に展開する処理が終わったと判断できるので、OSエントリにJUMPして、図5のフローチャートの処理を終了する。
一方、ステップS53の判断の結果、実行履歴に、ページ位置情報がまだある場合には、ステップS54に進む。
ステップS54に進むと、CPU11は、実行履歴からページ位置情報を取り出す。
ステップS54に進むと、CPU11は、実行履歴からページ位置情報を取り出す。
続いて、ステップS55において、CPU11は、ここでページ位置情報から該当するOSイメージのファイル位置を算出する。
続いて、ステップS56において、CPU11は、算出したファイル位置に対応するOSコードを1ページ分、メインメモリ12にロードする。
続いて、ステップS57において、CPU11は、次のページ位置情報をインデックスして、即ち、次のページ位置情報に進んで、ステップS53に戻る。
図6は、本発明の第1の実施形態を示し、OSコアがメモリにロードされ、bootからOSコアのエントリコードにJUMPした後の、OSコア内のページテーブル初期化処理の一例を示すフローチャートである。以下、各処理について述べる。
まず、ステップS61において、CPU11は、ページテーブルの全要素をすべて0で初期化する。ここで、ページテーブルの要素が0であると言う事は、そのページには何も割りあたっていない事を意味する。つまり、このアドレスへのアクセスは、ページフォルトとしてOSコアに検出される。
続いて、ステップS62において、CPU11は、OSコア部分に対応するページテーブルを初期化する。本実施形態では、OSコア部分のサイズを32KB、ページサイズを4KBと仮定しているので、8ページ分のページテーブルを初期化することになる。ここで、初期化するのは、ページテーブルの各要素、物理アドレスと属性ビットである。物理アドレスは、OSコアがマッピングされているアドレスであり、属性ビットは、本実施形態では1である。
続いて、ステップS63において、CPU11は、実行履歴に記録されているページ位置情報に対応するページテーブルを初期化する。ページ位置情報は、OSイメージに対するファイルページ位置として記録されているので、これを元にOSイメージがロードされている物理アドレスからのオフセットを算出し、ページテーブルの要素を初期化する。
続いて、ステップS64において、CPU11は、実行履歴のある全てのページ位置情報を0クリアする。これは、今回の再起動で新しい実行履歴の収集サイクルが始まるからである。このステップS64の処理が終了すると、図6のフローチャートの処理が終了する。
図7は、本発明の第1の実施形態を示し、ページフォルトが発生した時のOSコアにおける処理の一例を示すフローチャートである。以下、各処理について述べる。
まず、ステップS71において、CPU11は、ページフォルトを起こしたアドレスがOS空間であるか否かを判断する。この判断の結果、ページフォルトを起こしたアドレスがOS空間で無い場合には、そのページフォルトは、ユーザプログラムの引き起こした物なので、ステップS78に進み、通常のユーザプログラム向けページフォルト処理を行う。その後、図7のフローチャートの処理を終了する。
一方、ページフォルトを起こしたアドレスがOS空間である場合には、ステップS72に進む。
ステップS72に進むと、CPU11は、ステップS71に引き続き、ここでは、ページフォルトを起こしたアドレスがOSのコード領域であるか否かを判断する。この判断の結果、ページフォルトを起こしたアドレスがOSのコード領域で無い場合には、通常のOS空間におけるページフォルト(例えばメモリ確保)と判断できるので、ステップS79に進み、通常のOS空間におけるページフォルト処理を行う。その後、図7のフローチャートの処理を終了する。
ステップS72に進むと、CPU11は、ステップS71に引き続き、ここでは、ページフォルトを起こしたアドレスがOSのコード領域であるか否かを判断する。この判断の結果、ページフォルトを起こしたアドレスがOSのコード領域で無い場合には、通常のOS空間におけるページフォルト(例えばメモリ確保)と判断できるので、ステップS79に進み、通常のOS空間におけるページフォルト処理を行う。その後、図7のフローチャートの処理を終了する。
ステップS71とステップS72の判断で共に肯定判断だった場合には、ページフォルトアドレスがOSコード領域であると判断できる。よって、この場合は、OSコード領域のデマンドページングであるので、ステップS73以降に進む。
ステップS73に進むと、CPU11は、ページフォルトアドレスからOSイメージのファイルページ位置を算出する。
続いて、ステップS74において、CPU11は、ステップS73で算出したファイルページ位置を、実行履歴23に追記する。
続いて、ステップS75において、CPU11は、通常のデマンドページング処理を行い、OSイメージから該当するOSコードを1ページ分、メインメモリに展開する。
続いて、ステップS76において、メモリに展開したページに対応するページテーブルを更新し、再実行時に再びページフォルトが発生しないように、属性ビットとアドレス情報の更新を行う。
続いて、ステップS77において、CPU11は、ページフォルトを起こしたOSコードの再実行を行う。その後、図7のフローチャートの処理を終了する。ここまでの処理で、未ロードであった該当コードはメモリに展開され、さらに、対応するページテーブルも更新されているので、再実行は正常に行えるようになっている。
以上のように、本実施形態では、CPU11は、デマンドページング機構を利用した情報処理装置10において、ページフォルトを契機にしたデマンドページング機構によるデマンドページング時に、OSコードの実行履歴を収集する。また、CPU11は、収集したOSコードの実行履歴を外部記憶装置13に保存し、システムの再起動時にブートストラッププログラムであるboot25が参照できる。また、CPU11は、再起動時には、boot25が保存されたOSコードの実行履歴を元に、前回起動時に実行した実績のあるOSコードのみをメインメモリにロードする。
本実施形態によれば、実際に実行されたOSコード部分だけを起動時に展開する事が可能となり、起動スピードが向上する。
また、起動に必要な部分だけを展開するわけではないので、その後のOSの実行スピードの低下も最低限に抑える事が出来る。
また、起動に必要な部分だけを展開するわけではないので、その後のOSの実行スピードの低下も最低限に抑える事が出来る。
また、本実施形態では、CPU11は、再起動時に、前回起動時に実行した実績のあるOSコードのみをメインメモリにロードした場合、ロードした部分と未ロード部分をページテーブルを操作する事によって、未ロード部分だけが実行時にページフォルトを発生するように初期化する。また、CPU11は、実行履歴に、前回実行された部分が無い場合には、最低限必要なOS機能部分をロードする。
(第2の実施形態)
第1の実施形態では、実行履歴内のページ位置情報は、システムの起動中に無制限に収集するようになっていた。この場合、システムの起動期間が長かったり、様々な用途に使われたりすると、ページ位置情報がどんどん大きくなり最終的にOSイメージ本体に限りなく近くなってしまう。こうなると、再起動時にはOSイメージを全てロードする事とほとんど変わらなくなってしまい、システムが高速に起動しない恐れがある。
これに対処するため、第2の実施形態では、ページ位置情報の収集に上限を設けるものである。この場合、bootで上限値の判定を行う様にする。この上限値に達した場合には、それ以上のロードを中断してカーネルエントリにJUMPする。
具体的に、本実施形態では、CPU11は、実行履歴が所定のしきい値を超えて収集された場合には、上限を超えた部分を起動時にロードしない。
第1の実施形態では、実行履歴内のページ位置情報は、システムの起動中に無制限に収集するようになっていた。この場合、システムの起動期間が長かったり、様々な用途に使われたりすると、ページ位置情報がどんどん大きくなり最終的にOSイメージ本体に限りなく近くなってしまう。こうなると、再起動時にはOSイメージを全てロードする事とほとんど変わらなくなってしまい、システムが高速に起動しない恐れがある。
これに対処するため、第2の実施形態では、ページ位置情報の収集に上限を設けるものである。この場合、bootで上限値の判定を行う様にする。この上限値に達した場合には、それ以上のロードを中断してカーネルエントリにJUMPする。
具体的に、本実施形態では、CPU11は、実行履歴が所定のしきい値を超えて収集された場合には、上限を超えた部分を起動時にロードしない。
(第3の実施形態)
第1の実施形態では、デマンドページングが発生したOSコードは、全て実行履歴に保存していた。この手法では、ほとんど実行されない特別なエラーコードも記録されてしまう恐れがある。その様なコードは、再起動時にメモリに展開されても、ほとんどの場合、実行されないので無駄である。これに対処するために、第3の実施形態では、OSコードの中でほとんど実行されない部分を登録したテーブルを用意する。そして、デマンドページングが発生した時に、そのアドレスをこのテーブルと比較し、もしこのテーブルと一致した場合には実行履歴に記録せずに、通常のデマンドページングだけを行う。こうする事で、めったに発生しない例外コードが実行履歴に登録される事を防ぎ、再起動の速度低下を防ぐ事が可能となる。
具体的に、本実施形態では、CPU11は、OSコードの中でほとんど実行される事の無い、特別な例外処理部分に関する位置情報を持たせる事で、実行履歴がこれと一致する場合には、実行履歴としては保存せずに破棄する。
第1の実施形態では、デマンドページングが発生したOSコードは、全て実行履歴に保存していた。この手法では、ほとんど実行されない特別なエラーコードも記録されてしまう恐れがある。その様なコードは、再起動時にメモリに展開されても、ほとんどの場合、実行されないので無駄である。これに対処するために、第3の実施形態では、OSコードの中でほとんど実行されない部分を登録したテーブルを用意する。そして、デマンドページングが発生した時に、そのアドレスをこのテーブルと比較し、もしこのテーブルと一致した場合には実行履歴に記録せずに、通常のデマンドページングだけを行う。こうする事で、めったに発生しない例外コードが実行履歴に登録される事を防ぎ、再起動の速度低下を防ぐ事が可能となる。
具体的に、本実施形態では、CPU11は、OSコードの中でほとんど実行される事の無い、特別な例外処理部分に関する位置情報を持たせる事で、実行履歴がこれと一致する場合には、実行履歴としては保存せずに破棄する。
(第4の実施形態)
第1の実施形態では、実行履歴内のページ位置情報は、再起動時に0クリアされていた。この手法は、単純なので実装が簡単であるが、「OSコードの良く使う部分」を優先してロードする事は出来ない。
第1の実施形態では、実行履歴内のページ位置情報は、再起動時に0クリアされていた。この手法は、単純なので実装が簡単であるが、「OSコードの良く使う部分」を優先してロードする事は出来ない。
よって、第4の実施形態では、「OSコードの良く使う部分」を優先してロードするために、実行履歴内のページ位置情報を再起動時に0クリアしないようにする。そして、デマンドページング発生時に実行履歴内のページ位置情報をチェックし、もし同じ位置情報があった場合には、これをインクリメントする。この様にする事で、起動する毎に毎回アクセスされる「OSコードの良く使う部分」を明確にする事が出来る。
そして、bootでOSコアのロードに引き続き、実行履歴内のページ位置情報を元にしたロードをする段階で、ページ位置情報のカウントが大きいページを優先してロードする。この仕組みと第2の実施形態の仕組みを組み合わせれば、起動時間を犠牲にせずに実行頻度の高いOSコードのロードが可能となる。
具体的に、本実施形態では、CPU11は、実行履歴を起動する毎に収集し、かつその情報を1回ごとにクリアせずにカウントアップする事により実行頻度の高い部分を明確化し、当該実行頻度の高い部分だけをロードして実行効率を向上させる。
(第5の実施形態)
ここまで説明してきた、第1〜第4の各実施形態の全てを盛り込んだ実装も可能である。この場合、ページ位置情報の上限があり、かつ実行頻度の低いエラー処理コード等はロードされず、さらに過去に実行された実績のあるコードに順位がつけられ、それに従ってそれらが優先的にロードされるようになる。
ここまで説明してきた、第1〜第4の各実施形態の全てを盛り込んだ実装も可能である。この場合、ページ位置情報の上限があり、かつ実行頻度の低いエラー処理コード等はロードされず、さらに過去に実行された実績のあるコードに順位がつけられ、それに従ってそれらが優先的にロードされるようになる。
[作用]
本発明における実施形態では、「通常の使用において巨大なOSコード全てを使う事はない」という前提に立ってなされている。例えばOSの構成要素が、割込み管理、メモリ管理、ファイル管理、プロセス管理、ネットワーク管理、デバイス管理・・・などで構成されているとする。この時、HDDだけを使うならデバイス管理の中のIDEに関するOSコードは実行されるが、同じデバイス管理のSCSI−diskに関するOSコードは不要のはずである。同様に、ファイルシステム機能でFATファイルシステムを使うなら対応するコードは必要であるが、NFSを使用しないならそのコードは不要である。
本発明における実施形態では、「通常の使用において巨大なOSコード全てを使う事はない」という前提に立ってなされている。例えばOSの構成要素が、割込み管理、メモリ管理、ファイル管理、プロセス管理、ネットワーク管理、デバイス管理・・・などで構成されているとする。この時、HDDだけを使うならデバイス管理の中のIDEに関するOSコードは実行されるが、同じデバイス管理のSCSI−diskに関するOSコードは不要のはずである。同様に、ファイルシステム機能でFATファイルシステムを使うなら対応するコードは必要であるが、NFSを使用しないならそのコードは不要である。
また、OSはあらゆる不測の事態に備えて、非常に緻密なエラーリカバリコードを抱え込んでいる。これらのコードは、重要ではあるものの、殆どの場合、実行されないままである。この様に、実際には実行されない機能を抱え込んでいるにもかかわらず、OSとしてはユーザがどの機能を使うか事前に想定する事は出来ないため、全ての機能を詰め込んだ「全部入り」のOSイメージを作り準備しなければならない。これが、OSイメージが数MBを超える原因の1つになっている。
本発明における実施形態では、上記実行されないコードは起動時にロードせず、実行した実績のあるコードだけをロードする事で起動高速化を実現する。
このOSで実際に実行されたコード(=実行履歴)の取得には、プロセッサのページフォルト機構とOSの標準機構であるデマンドページング機構を活用する。デマンドページング機構は、ページフォルトを利用して、メモリにロードされていないコードへのアクセスを検出する。この様なアクセスを検出すると、ページフォルト割込みがプロセッサから通知され、OSのページフォルトハンドラに制御が移る。ページフォルトハンドラは、ロードされていないコード位置を算出し、外部記憶装置又は不揮発メモリからメインメモリにコードを1ページ分展開し、そのコードを再実行する。
このOSで実際に実行されたコード(=実行履歴)の取得には、プロセッサのページフォルト機構とOSの標準機構であるデマンドページング機構を活用する。デマンドページング機構は、ページフォルトを利用して、メモリにロードされていないコードへのアクセスを検出する。この様なアクセスを検出すると、ページフォルト割込みがプロセッサから通知され、OSのページフォルトハンドラに制御が移る。ページフォルトハンドラは、ロードされていないコード位置を算出し、外部記憶装置又は不揮発メモリからメインメモリにコードを1ページ分展開し、そのコードを再実行する。
つまり、デマンドページング機構は、「実際に実行されたコード」の位置情報を、ページフォルトによって取得する事が出来る。本発明における実施形態では、このデマンドページング機構のページフォルト検出処理を利用し、そのコード位置情報を実行履歴として外部記憶装置又は不揮発メモリに保存する。この様に位置情報を収集しておけば、再起動時に実際にロードすべきコード位置情報をbootに渡す事が可能になる。そして、bootコードはこの実行履歴を元に、OSで実際に実行された部分だけをメモリに展開して起動する。
上記の様な構成を採れば、実際に実行されたOSコード部分だけを起動時に展開する事が可能となり、起動スピードが向上する。
また起動に必要な部分だけを展開するわけではないので、その後のOSの実行スピードの低下も最低限に抑える事が出来る。
また起動に必要な部分だけを展開するわけではないので、その後のOSの実行スピードの低下も最低限に抑える事が出来る。
(その他の実施形態)
また、本発明は、以下の処理を実行することによっても実現される。
即ち、上述した実施形態の機能を実現するソフトウェア(プログラム)を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ(またはCPUやMPU等)がプログラムを読み出して実行する処理である。
このプログラム及び当該プログラムを記憶したコンピュータ読み取り可能な記録媒体は、本発明に含まれる。
また、本発明は、以下の処理を実行することによっても実現される。
即ち、上述した実施形態の機能を実現するソフトウェア(プログラム)を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ(またはCPUやMPU等)がプログラムを読み出して実行する処理である。
このプログラム及び当該プログラムを記憶したコンピュータ読み取り可能な記録媒体は、本発明に含まれる。
12 メインメモリ、13 外部記憶装置、14 不揮発メモリ、21 OSコア、22 デマンドページング機構、23 実行履歴、24 OSイメージ、25 boot(ブートストラッププログラム)
Claims (9)
- デマンドページング機構を利用した情報処理装置であって、
ページフォルトを契機にした前記デマンドページング機構によるデマンドページング時に、OSコードの実行履歴を収集する収集手段と、
前記収集手段で収集したOSコードの実行履歴を外部記憶装置に保存し、システムの再起動時にブートストラッププログラムが参照できる参照手段と、
前記再起動時には、前記ブートストラッププログラムが前記保存されたOSコードの実行履歴を元に、前回起動時に実行した実績のあるOSコードのみをメインメモリにロードするロード手段と
を具備する事を特徴とする情報処理装置。 - 前記保存されたOSコードの実行履歴を元に、前回実行された部分だけを起動時にメインメモリにロードして、システムを高速に起動する事を特徴とする請求項1に記載の情報処理装置。
- 前記再起動時に、前回起動時に実行した実績のあるOSコードのみをメインメモリにロードした場合、ロードした部分と未ロード部分をページテーブルを操作する事によって、未ロード部分だけが実行時に前記ページフォルトを発生するように初期化する初期化手段を更に具備する事を特徴とする請求項1又は2に記載の情報処理装置。
- 前記実行履歴に、前回実行された部分が無い場合には、最低限必要なOS機能部分をロードする事を特徴とする請求項1乃至3のいずれか1項に記載の情報処理装置。
- 前記実行履歴が前記外部記憶装置に存在しない場合には、前記OSコードの全体をロードする事を特徴とする請求項1乃至4のいずれか1項に記載の情報処理装置。
- 前記実行履歴が所定のしきい値を超えて収集された場合には、上限を超えた部分を起動時にロードしない事を特徴とする請求項1乃至5のいずれか1項に記載の情報処理装置。
- 前記OSコードの中でほとんど実行される事の無い、特別な例外処理部分に関する位置情報を持たせる事で、前記実行履歴がこれと一致する場合には、前記実行履歴としては保存せずに破棄することを特徴とする請求項1乃至6のいずれか1項に記載の情報処理装置。
- 前記実行履歴を起動する毎に収集し、かつその情報を1回ごとにクリアせずにカウントアップする事により実行頻度の高い部分を明確化し、当該実行頻度の高い部分だけをロードして実行効率を向上させる事を特徴とする請求項1乃至7のいずれか1項に記載の情報処理装置。
- デマンドページング機構を利用した情報処理装置による情報処理方法であって、
ページフォルトを契機にした前記デマンドページング機構によるデマンドページング時に、OSコードの実行履歴を収集する収集ステップと、
前記収集ステップで収集したOSコードの実行履歴を外部記憶装置に保存し、システムの再起動時にブートストラッププログラムが参照できる参照ステップと、
前記再起動時には、前記ブートストラッププログラムが前記保存されたOSコードの実行履歴を元に、前回起動時に実行した実績のあるOSコードのみをメインメモリにロードするロードステップと
を具備する事を特徴とする情報処理方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2010276377A JP2012123762A (ja) | 2010-12-10 | 2010-12-10 | 情報処理装置及び情報処理方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2010276377A JP2012123762A (ja) | 2010-12-10 | 2010-12-10 | 情報処理装置及び情報処理方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2012123762A true JP2012123762A (ja) | 2012-06-28 |
Family
ID=46505108
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2010276377A Pending JP2012123762A (ja) | 2010-12-10 | 2010-12-10 | 情報処理装置及び情報処理方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2012123762A (ja) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2012128841A (ja) * | 2010-12-14 | 2012-07-05 | Internatl Business Mach Corp <Ibm> | ブート・ブロックの再配置によって複数のソフトウェア・イメージを管理するための方法、コンピュータ・プログラムおよびシステム |
| KR101618992B1 (ko) | 2014-12-19 | 2016-05-10 | 주식회사 엘지유플러스 | 가상 데스크탑 서비스 제공 시스템 및 그 제어방법과, 그 제어방법을 실행하기 위한 프로그램을 기록한 기록 매체와, 하드웨어와 결합되어 그 제어방법을 실행시키기 위하여 매체에 저장된 애플리케이션 |
| JP2017520875A (ja) * | 2014-06-30 | 2017-07-27 | サイプレス セミコンダクター コーポレーション | 複数メモリからのアプリケーション起動 |
| JP2018010452A (ja) * | 2016-07-13 | 2018-01-18 | 株式会社バッファローメモリ | 記憶装置、情報処理システム、記憶装置の起動方法及びプログラム |
| CN114168224A (zh) * | 2021-12-06 | 2022-03-11 | 杭州筑龙信息技术股份有限公司 | 应用程序的启动方法、装置、电子设备及存储介质 |
-
2010
- 2010-12-10 JP JP2010276377A patent/JP2012123762A/ja active Pending
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2012128841A (ja) * | 2010-12-14 | 2012-07-05 | Internatl Business Mach Corp <Ibm> | ブート・ブロックの再配置によって複数のソフトウェア・イメージを管理するための方法、コンピュータ・プログラムおよびシステム |
| JP2017520875A (ja) * | 2014-06-30 | 2017-07-27 | サイプレス セミコンダクター コーポレーション | 複数メモリからのアプリケーション起動 |
| KR101618992B1 (ko) | 2014-12-19 | 2016-05-10 | 주식회사 엘지유플러스 | 가상 데스크탑 서비스 제공 시스템 및 그 제어방법과, 그 제어방법을 실행하기 위한 프로그램을 기록한 기록 매체와, 하드웨어와 결합되어 그 제어방법을 실행시키기 위하여 매체에 저장된 애플리케이션 |
| JP2018010452A (ja) * | 2016-07-13 | 2018-01-18 | 株式会社バッファローメモリ | 記憶装置、情報処理システム、記憶装置の起動方法及びプログラム |
| CN114168224A (zh) * | 2021-12-06 | 2022-03-11 | 杭州筑龙信息技术股份有限公司 | 应用程序的启动方法、装置、电子设备及存储介质 |
| CN114168224B (zh) * | 2021-12-06 | 2024-02-20 | 杭州筑龙信息技术股份有限公司 | 应用程序的启动方法、装置、电子设备及存储介质 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8392694B2 (en) | System and method for software initiated checkpoint operations | |
| JP4740238B2 (ja) | アプリケーションを再起動するときに、アプリケーション状態の履歴情報を使用する方法、ソフトウェア、および装置 | |
| US9189248B2 (en) | Specialized boot path for speeding up resume from sleep state | |
| US7941700B2 (en) | Operating system-based application recovery | |
| CN104254840B (zh) | 在计算机系统中的存储器转储和分析 | |
| US11232026B2 (en) | Deferred destruction for efficient resource reclamation | |
| EP2854032B1 (en) | Method and apparatus for restoring exception data in internal memory | |
| JP2012123762A (ja) | 情報処理装置及び情報処理方法 | |
| CN103559119B (zh) | 文件操作请求处理方法及装置 | |
| US8468388B2 (en) | Restoring programs after operating system failure | |
| CN103092695A (zh) | 信息处理装置及信息处理装置的启动模式间的切换方法 | |
| JP2005222366A (ja) | 自動復帰方法/プログラム/プログラム記録媒体、処理装置 | |
| KR20130002692A (ko) | 백신과 컴퓨터 최적화 기능을 구비한 컴퓨터 최적화 방법, 최적화 서버 및 컴퓨터 판독 가능한 기록매체 | |
| KR100994723B1 (ko) | 시스템에서 초기 구동시간을 단축시키는 선택적 서스펜드 리쥼 방법 및 그 기록매체 | |
| CN113901443A (zh) | 守护进程故障检测方法及装置、存储介质及电子设备 | |
| KR100575657B1 (ko) | 낸드 플래시 읽기 방법 | |
| US10592329B2 (en) | Method and electronic device for continuing executing procedure being aborted from physical address where error occurs | |
| JP5577518B2 (ja) | メモリ管理方法、計算機及びメモリ管理プログラム | |
| CN103677202B (zh) | 休眠管理方法及相关装置 | |
| CN119248360B (zh) | 休眠流程中镜像异常恢复方法、装置及存储介质 | |
| JP2010277495A (ja) | 圧縮記録装置および圧縮記録方法 | |
| CN111400076B (zh) | 一种宕机修复方法、装置、设备及存储介质 | |
| US20160266960A1 (en) | Information processing apparatus and kernel dump method | |
| JP2007172519A (ja) | 情報処理装置、ソフトウェアモジュールのリンク管理方法及びプログラム | |
| JP2007156702A (ja) | オペレーティングシステム |