WO2023007618A1 - 情報処理装置 - Google Patents

Abstract

本開示は、専用ハードウェアを備えることなくアプリケーションの実行状況に応じてオペレーティングシステムによるジッタを削減することが可能な情報処理装置を提供することを目的とする。本開示による情報処理装置は、複数のプロセッサコアを含む演算装置とオペレーティングシステムとを備え、オペレーティングシステムは、オペレーティングシステムのＯＳジッタ統計情報を取得するＯＳジッタ統計情報取得部と、ＯＳジッタ統計情報に対応付けられたＯＳジッタレベルが規定されたＯＳジッタ統計情報テーブルと、アプリケーションの入力値を取得する入力値取得部と、入力値に対応付けられた演算負荷レベルが規定された演算負荷テーブルと、ＯＳジッタレベルおよび演算負荷レベルに基づいて処理ブロックをオペレーティングシステムが実行されないベアメタル環境で実行する必要があるか否かを判定するベアメタル要否判定部とを備える。

Description

情報処理装置

　本開示は、リアルタイムシステムにおけるアプリケーションの実行状況に基づいて、オペレーティングシステムによるジッタを削減した実行環境を提供する情報処理装置に関する。

　従来、リアルタイムシステムにおけるコントローラは、アプリケーション（リアルタイムアプリケーション）のリアルタイム性を保証するために、専用のＲＴＯＳ（Real Time Operating System）を採用してきた。近年、単一の高性能コントローラ上で、高リアルタイム性が要求される制御系アプリケーションと、情報系アプリケーションとを同時運用して相互に連携し合うといった統合化および分散協調が図られている。しかし、ＲＴＯＳは、リアルタイム性の保証に特化した機能しか持たず、ＩｏＴ（Internet of Things）またはＡＩ（Artificial Intelligence）技術を活用した情報系アプリケーションに必要なライブラリおよびランタイム等の実行環境を提供していない。そのため、リアルタイムシステムでは、Ｌｉｎｕｘ（登録商標、以下同じ）等の汎用ＯＳ（Operating System）を採用したコントローラが普及している。

　汎用ＯＳは、多様な処理を行うため、制御系アプリケーションおよび情報系アプリケーションのみならず、カーネル内のスレッド処理、および他の機器との接続を行うためのＩ/Ｏ処理等、汎用ＯＳ自身の処理によるジッタ（以下、「ＯＳジッタ」という）がＲＴＯＳと比べて大きいため、リアルタイム性の保証が困難である。加えて、上述したコントローラの統合化および分散協調により、システムが大規模になるほど、一つのアプリケーションの処理時間がＯＳジッタによって伸長することは、システム全体の性能に影響を及ぼし易くなる。例えば、ＦＡ（Factory Automation）分野におけるビジュアルフィードバックでは、画像処理アプリケーションはそれ自体がハードリアルタイムではないかも知れないが、後続の位置決め等を行う制御系アプリケーションがハードリアルタイムである場合、画像処理アプリケーションの実行中に処理時間の長いＯＳジッタが発生することによって制御系アプリケーションが落ちることは回避されなければならない。このように、リアルタイムシステムでは、発生頻度は低くても処理時間が長いＯＳジッタにも対処することが、今後の新たな課題としてより一層の対処が求められる。

　コントローラの統合化および分散協調は、一方で、ソフトウェアアップデートおよびアプリケーションの追加といった機能進化の側面も併せ持つ。システムを運用していく中で、アプリケーションの実行状況が経時的に変化し、それに伴ってＯＳジッタの発生状況も変化する。アプリケーションの実行状況によっては、ＯＳジッタがシステム全体の性能にクリティカルに影響するため削減しなければならないケース、または、反対に対処する必要がないケースが考えられる。そのため、アプリケーションの実行状況に応じて、動的にＯＳジッタを削減する実行環境が求められる。

　従来のリアルタイムアプリケーションを実行する情報処理装置では、アプリケーションの一部実行処理時に、ＦＰＧＡ（Field Programmable Gate Array）などの専用ハードウェアに一部処理をオフロードすることによって、汎用ＯＳでの性能の揺らぎおよび他アプリケーションの干渉を抑制している（例えば、特許文献１参照）。

特開２０２０－１６６４２７号公報

　特許文献１のようなリアルタイムアプリケーションを実行する情報処理装置は、専用ハードウェアが装置に予め具備されていることを前提としているため、専用ハードウェアを搭載しない情報処理装置には適用することができない、あるいは製品化のコストが高くなるという問題点があった。また、動的に専用ハードウェアにアプリケーションの一部処理をオフロードする機構は備えていない。そのため、アプリケーションの実況状況の変化に応じて、オペレーティングシステムのジッタを削減することができないという問題点があった。

　本開示は、このような問題を解決するためになされたものであり、専用ハードウェアを備えることなく、アプリケーションの実行状況に応じてオペレーティングシステムによるジッタを削減することが可能な情報処理装置を提供することを目的とする。

　上記の課題を解決するために、本開示による情報処理装置は、複数のプロセッサコアを含む演算装置と、演算装置で実行されるオペレーティングシステムとを備え、アプリケーションを実行する情報処理装置であって、オペレーティングシステムは、オペレーティングシステムの処理において発生するＯＳジッタの統計情報であるＯＳジッタ統計情報を取得するＯＳジッタ統計情報取得部と、ＯＳジッタ統計情報に対応付けられたＯＳジッタのレベルであるＯＳジッタレベルが規定されたＯＳジッタ統計情報テーブルと、アプリケーションの入力値を取得する入力値取得部と、入力値に対応付けられた、アプリケーションを構成する処理ブロックの演算負荷のレベルである演算負荷レベルが規定された演算負荷テーブルと、ＯＳジッタレベルおよび演算負荷レベルに基づいて、処理ブロックをオペレーティングシステムが実行されないベアメタル環境で実行する必要があるか否かを判定するベアメタル要否判定部とを備える。

　本開示によれば、専用ハードウェアを備えることなく、アプリケーションの実行状況に応じてオペレーティングシステムによるジッタを削減することが可能となる。

　本開示の目的、特徴、態様、および利点は、以下の詳細な説明と添付図面とによって、より明白となる。

実施の形態１による情報処理装置の構成の一例を示すブロック図である。 実施の形態１によるＯＳジッタ統計情報取得部の動作の一例を示すフローチャートである。 実施の形態１によるＯＳジッタ統計情報テーブルの一例を示す図である。 実施の形態１によるＯＳジッタが発生した場合における処理時間変動のイメージの一例を示す図である。 実施の形態１による入力値取得部の動作の一例を示すフローチャートである。 実施の形態１による演算負荷テーブルの一例を示す図である。 実施の形態１によるベアメタル要否判定テーブルの一例を示す図である。 実施の形態１によるベアメタル要否判定部の動作の一例を示すフローチャートである。 実施の形態１によるベアメタル構築部の動作の一例を示すフローチャートである。 実施の形態１によるベアメタル構築レイテンシテーブルの一例を示す図である。 実施の形態１によるベアメタルローダ部の動作の一例を示すフローチャートである。 実施の形態１によるベアメタル連携部の動作の一例を示すフローチャートである。 実施の形態１による演算アプリ生成部の動作の一例を示すフローチャートである。 実施の形態１による関数テーブルの一例を示す図である。 実施の形態２による情報処理装置の構成の一例を示すブロック図である。 実施の形態２によるキャッシュ統計情報テーブルの一例を示す図である。 実施の形態２によるベアメタル要否判定テーブルの一例を示す図である。 実施の形態２によるベアメタル要否判定部の動作の一例を示すフローチャートである。 実施の形態３による情報処理装置の構成の一例を示すブロック図である。 実施の形態３による演算負荷学習部の動作の一例を示すフローチャートである。 実施の形態３による演算負荷推定部の動作の一例を示すフローチャートである。

　＜実施の形態１＞
　図１は、実施の形態１による情報処理装置１０００の構成の一例を示すブロック図である。

　情報処理装置１０００は、演算装置１００１および記憶装置１００２を備えている。情報処理装置１０００は、ＮＷ（Network）装置１００３を介してネットワーク１００５に接続されており、ＩＯ（Input Output）装置１００４からのデータを取得する。ＮＷ装置１００３は、シリアル通信、Ethernet（登録商標）等であり、１以上のＩＯ装置１００４と演算装置１００１との接続を形成している。ＩＯ装置１００４は、例えば、各種のセンサである。

　演算装置１００１は、各種のプログラムを実行する。演算装置１００１は、１以上のプロセッサ１１００で構成されている。プロセッサ１１００は、例えばＣＰＵ（Central Processing Unit）である。プロセッサ１１００は、２以上のプロセッサコア１１００－１～１１００－４を備える。なお、図１では、４つのプロセッサコア１１００－１～１１００－４を示しているが、これに限定されるものではない。

　記憶装置１００２は、プログラムおよびプログラムの実行に必要なデータを格納する。記憶装置１００２は、例えば、キャッシュメモリ、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、またはＨＤＤ（Hard Disk Drive）等である。

　次に、記憶装置１００２の機能構成について説明する。記憶装置１００２は、オペレーティングシステム１２００およびコンパイラ部１３００を備える。オペレーティングシステム１２００は、Ｌｉｎｕｘ等の汎用ＯＳであり、汎用ＯＳが備える機能を有する。コンパイラ部１３００では、ＯＳが実行される環境（以下、「ＯＳ環境（オペレーティングシステム環境）」という）と、ＯＳが実行されない環境（以下、「ベアメタル環境」という）との両方で実行可能な実行バイナリを、演算アプリ生成部１３１０によって生成する。以下、ＯＳ環境で実行可能な実行バイナリのことを「ＯＳ環境用実行バイナリ（オペレーティングシステム環境用実行バイナリ）」といい、ベアメタル環境で実行可能な実行バイナリのことを「ベアメタル環境用実行バイナリ」という。ＯＳ環境用実行バイナリおよびベアメタル環境用実行バイナリは、演算アプリ本体コード１３２０および関数テーブル１３３０から生成された演算アプリ合成コード１３４０に基づいて生成される。

　オペレーティングシステム１２００は、ＯＳジッタ同定部１２１０と、演算負荷同定部１２２０と、テーブル設定Ｉ/Ｆ１２３０と、ベアメタル制御部１２４０とを備える。

　ＯＳジッタ同定部１２１０は、ＯＳジッタ統計情報取得部１２１１およびＯＳジッタ統計情報テーブル１２１２を備える。ＯＳジッタ統計情報取得部１２１１は、オペレーティングシステムの各種処理に関する統計情報を取得する。ＯＳジッタ統計情報テーブル１２１２は、ＯＳジッタの種類とモニタリングする項目ごとに、それぞれ数値範囲とそれに対応するレベル（ＯＳジッタレベル）とをユーザが事前に規定する。ＯＳジッタ統計情報取得部１２１１およびＯＳジッタ統計情報テーブル１２１２に基づいて、現在のＯＳジッタレベルが同定される。

　演算負荷同定部１２２０は、入力値取得部１２２１および演算負荷テーブル１２２２を備える。入力値取得部１２２１は、ＮＷ装置１００３を介してＩＯ装置１００４からの入力値を取得する。演算負荷テーブル１２２２は、入力値に対応付けて、処理時間の数値範囲とそれに対応するレベル（演算負荷レベル）とをユーザが事前に規定する。入力値取得部１２２１および演算負荷テーブル１２２２に基づいて、現在の演算負荷レベルが同定される。

　ベアメタル制御部１２４０は、ベアメタル要否判定テーブル１２４１、ベアメタル要否判定部１２４２、ベアメタル構築部１２４３、ベアメタル構築レイテンシテーブル１２４４、ベアメタルローダ部１２４５、およびベアメタル連携部１２４６を備える。ユーザは、テーブル設定Ｉ/Ｆ１２３０を介して、各処理ブロックをベアメタル環境で実行するために必要な条件を設定し、その設定がベアメタル要否判定テーブル１２４１に反映される。なお、処理ブロックの粒度は、アプリケーションの単位でも良く、アプリケーションの構成要素の単位（例えば、関数）でも良い。

　ベアメタル要否判定部１２４２は、ＯＳジッタ同定部１２１０によって同定された現在のＯＳジッタレベルと、演算負荷同定部１２２０によって同定された現在の演算負荷レベルとを、ベアメタル要否判定テーブル１２４１に問い合わせ、該当処理ブロック（実行対象の処理ブロック）をベアメタル環境で実行すべきか否かを判定する。

　ベアメタル構築部１２４３は、該当処理ブロックの判定結果に基づいて、プロセッサコア１１００―１～１１００―４のうちのいずれか１以上のプロセッサコアに対してベアメタル環境を構築する。

　ベアメタル構築レイテンシテーブル１２４４は、ベアメタル環境の構築に要するオペレーションのオーバヘッド時間を保持し、ベアメタル環境の構築時に遅延影響が出ないように制御するために用いられる。

　ベアメタルローダ部１２４５は、該当処理ブロックのベアメタル環境用実行バイナリを予め定められた仮想アドレスに展開する。ベアメタル連携部１２４６は、ベアメタル環境用実行バイナリの実行ステータスに基づいて、ＯＳ環境用実行バイナリの実行制御を行う。

　図２は、ＯＳジッタ統計情報取得部１２１１の動作の一例を示すフローチャートである。

　ステップＳ１００１において、ＯＳジッタ統計情報取得部１２１１は、ユーザによって設定されたＯＳジッタの種類の情報を、後述するＯＳジッタ統計情報テーブル１２１２から取得する。

　ステップＳ１００２において、ＯＳジッタ統計情報取得部１２１１は、取得したＯＳジッタの種類について、汎用ＯＳが提供するシステム監視ツールを用いてその統計情報を取得する。例えば、Ｌｉｎｕｘでカーネル処理に関する統計情報を取得する場合、ｔｏｐコマンドを用いることによってユーザ時間割合またはシステム時間割合を取得することができる。

　図３は、ＯＳジッタ統計情報テーブル１２１２の一例を示す図である。

　ＯＳジッタ統計情報テーブル１２１２は、ユーザによって選択されたＯＳジッタの種類について、モニタリングする項目と、各項目の数値範囲に対応したＯＳジッタレベルとを保持するテーブルである。ＯＳジッタは、例えば、オペレーティングシステムにおけるカーネル処理、IO処理、メモリ管理など様々な種類がある。ユーザは、準備段階時に、ＯＳジッタの種類、種類ごとのモニタリング項目、およびモニタリング項目ごとの数値範囲とＯＳジッタレベルとを設定する。

　図３の例では、ＯＳジッタの種類として、カーネル処理１２１２－１、ＩＯ処理１２１２－２、およびメモリ管理１２１２－３の３つを設定している。また、カーネル処理１２１２―１では、モニタリング項目として、ユーザ時間割合、コンテキストスイッチ数、およびシステム時間割合の３つを設定している。なお、ＯＳジッタの種類およびモニタリング項目は、これらに限定されるものではない。モニタリング項目は、１種類のＯＳジッタにつき１つでも良く、複数でも良い。複数の場合は、ＡＮＤ条件とする項目を同じ欄に設定し、ＯＲ条件とする項目をそれぞれ異なる欄に設定する。図３の例では、カーネル処理１２１２―１に関して、ユーザ時間割合およびコンテキストスイッチ数は、互いにＡＮＤ条件とするために「項目１」の欄に設定している。システム時間割合は、ユーザ時間割合およびコンテキストスイッチ数をＯＲ条件とするために「項目２」の欄に設定している。また、ＯＳジッタレベルは、「低」、「中」、および「高」の３段階設定とし、各レベルでモニタリング項目の数値範囲を設定している。なお、ＯＳジッタレベルおよび数値範囲は、これらに限定されるものではない。

　図４は、ＯＳジッタが発生した場合における処理時間変動のイメージの一例を示す図である。

　上述したオペレーティングシステムのカーネル処理、ＩＯ処理、およびメモリ管理等のＯＳジッタは、アプリケーションの実行状況によって時々刻々と発生の確立分布が変動する。例えば、実行されるアプリケーションの数が増大したとき、または実行中のアプリケーションの処理負荷が増大したときに、カーネル内のスレッドはスケジューリングされにくくなるため１回の実行あたりの処理時間が増大するケースがある。その他、物理メモリが枯渇してメモリ管理機能によりページアウトまたはスワップが頻繁に発生するケースも想定される。

　図４の例では、ＯＳジッタレベルが「低」、「中」、および「高」と変動した場合において処理ブロックの処理時間が変動する様子を模式的に表しており、システム全体の性能に影響が出ないようにアプリケーションの実行状況に応じて、シビアにＯＳジッタを対処しなければならないケースがあることを示唆している。例えば、あるアプリケーションにおいて、ＯＳジッタレベルが「低」のときは、システム全体に重大エラーを引き起こすような処理時間が長いＯＳジッタが発生する確率が限りなく低いため、対処する必要はない。一方、ＯＳジッタレベルが「高」のときは、その確率が５０%以上と高くなるため、対処しなければならないといったケースが想定される。

　図５は、入力値取得部１２２１の動作の一例を示すフローチャートである。

　情報処理装置１０００が準備段階か、または運用段階かによって処理内容が異なる。

　ステップＳ１１０１において、入力値取得部１２２１は、情報処理装置１０００が準備段階か否かを判断する。

　ステップＳ１１０２において、入力値取得部１２２１は、ＩＯ装置１００４から入力値を取得する割込みハンドラ関数を、割込みベクタテーブルに事前登録する。対象の演算アプリによって取得する入力値は異なるため、この割込みハンドラ関数はユーザによって定義されるものである。

　ステップＳ１１０３において、運用段階に移り、入力値取得部１２２１は、ＮＷ装置１００３からのハードウェア割込みを検出すると、登録した割込みハンドラ関数を呼び出す。

　ステップＳ１１０４において、入力値取得部１２２１は、ＩＯ装置１００４からの入力値を取得する。

　図６は、演算負荷テーブル１２２２の一例を示す図である。

　ユーザは、準備段階時に、入力値に対応付けて処理ブロックごとの処理時間および処理負荷レベルを設定する。処理時間の計測については、例えば、準備段階時に対象とするアプリケーションのみをベアメタル環境で実行し、処理ブロックごとの処理時間を計測する。

　図６の例では、処理ブロックＡはテーブル１２２２－１、処理ブロックＢはテーブル１２２２－２、処理ブロックＣはテーブル１２２２－３といった具合で、処理ブロックごとに別のテーブルとする。演算負荷レベルについては、ユーザが準備段階時に処理時間に対して数値範囲を決めて定義するものである。図６では、「低」、「中」、および「高」の３段階としているが、これに限定されるものではない。

　図７は、ベアメタル要否判定テーブル１２４１の一例を示す図である。

　ユーザは、準備段階時にテーブル判定Ｉ/Ｆ１２３０を介して、先行処理ブロック（該当処理ブロックの１つ前に行う処理ブロック）、および処理ブロックごとのベアメタル実行条件を設定する。ベアメタル実行条件とは、該当処理ブロックがベアメタル環境での実行が必要となる条件のことをいう。ベアメタル環境での実行が必要な条件として、ＯＳジッタ統計情報テーブル１２１２のＯＳジッタの種類とそのＯＳジッタレベル、またはユーザが準備段階時に設定する演算負荷テーブル１２２２の演算負荷レベルを、ベアメタル実行条件欄に設定する。このとき、ＡＮＤ条件とするＯＳジッタの種類または演算負荷は同じ欄に設定し、ＯＲ条件とするＯＳジッタの種類または演算負荷はそれぞれ異なる欄に設定する。

　図７の例では、処理ブロックＡについて、カーネル処理および演算負荷を互いにＡＮＤ条件とするために「条件１」の欄に設定し、ＩＯ処理は、カーネル処理および演算負荷をＯＲ条件とするために「条件２」の欄に設定している。なお、ＯＳジッタ統計情報テーブル１２１２で設定したＯＳジッタの種類、および演算負荷テーブル１２２２で設定した演算負荷のうち、すべてを設定する必要はなく、該当処理ブロックがベアメタル環境での実行が必要と判断するために必要なもののみを設定すれば良い。

　図８は、ベアメタル要否判定部１２４２の動作の一例を示すフローチャートである。なお、ベアメタル要否判定部１２４２によるベアメタル要否判定の処理は、該当処理ブロックの先行処理ブロックの実行時に行うことを想定している。

　ステップＳ１２０１において、ベアメタル要否判定部１２４２は、ＯＳジッタ統計情報取得部１２１１から現在のＯＳジッタ統計情報を取得し、ＯＳジッタ統計情報テーブル１２１２に問い合わせて、対応するＯＳジッタレベルを取得する。

　ステップＳ１２０２において、ベアメタル要否判定部１２４２は、入力値取得部１２２１が取得した入力値に対応する該当処理ブロックの処理時間を演算負荷テーブル１２２２に問い合わせて、該当処理ブロックの演算負荷レベルを取得する。

　ステップＳ１２０３において、ベアメタル要否判定部１２４２は、現在のＯＳジッタレベルおよび演算負荷レベルをベアメタル要否判定テーブル１２４１に問い合わせて、現在のＯＳジッタレベルおよび演算負荷レベルが該当処理ブロックのベアメタル実行条件に当てはまるか否かを確認する。ベアメタル実行条件に当てはまる場合は、ステップＳ１２０４に移行する。一方、ベアメタル実行条件に当てはまらない場合は、ステップＳ１２０５に移行する。

　ステップＳ１２０４において、ベアメタル要否判定部１２４２は、該当処理ブロックがベアメタル環境での実行が必要であると判定する。

　ステップＳ１２０５において、ベアメタル要否判定部１２４２は、ベアメタル環境での実行が不要であると判定する。

　図９は、ベアメタル構築部１２４３の動作の一例を示すフローチャートである。

　ステップＳ１３０１において、ベアメタル構築部１２４３は、該当処理ブロックがベアメタル環境での実行が必要と判定されたか否かを確認する。ベアメタル環境での実行が必要である場合は、ステップＳ１３０２に移行する。一方、ベアメタル環境での実行が必要でない場合は、図９の動作を終了する。

　ステップＳ１３０２において、ベアメタル構築部１２４３は、該当処理ブロックが並列実行（マルチコア並列実行）されるか否かを判定する。当該判定は、演算アプリ本体コード１３２０の該当処理ブロックにあたる箇所に、並列化ライブラリ（例えば、ＯｐｅｎＭＰ（登録商標））のディレクティブが挿入されているか否かを検出することにより行う。該当処理ブロックが並列実行される場合、該当処理ブロックが要求するコア数は、並列化ライブラリの環境変数を参照することによって同定することができる。

　ステップＳ１３０３において、ベアメタル構築部１２４３は、ステップＳ１３０１において該当処理ブロックがベアメタル環境での実行が必要と判定した場合、すでに必要な数のコアに対して、ベアメタル環境を構築しているか否かを確認する。必要な数のコアに対してベアメタル環境を構築している場合は、ステップＳ１３０４に移行する。一方、必要な数のコアに対してベアメタル環境を構築していない場合は、ステップＳ１３０６に移行する。

　ステップＳ１３０４において、ベアメタル構築部１２４３は、すでに必要な数より多い数のコアに対してベアメタル環境を構築しているか否かを確認する。すでに必要な数より多い数のコアに対してベアメタル環境を構築している場合は、図９の動作を終了する。一方、すでに必要な数より多い数のコアに対してベアメタル環境を構築していない場合は、ステップＳ１３０５に移行する。

　ステップＳ１３０５において、ベアメタル構築部１２４３は、例えば、オペレーティングシステム１２００が有するＨｏｔｐｌｕｇ機能を使用して不要な数のコアを論理オンとすることによって、オペレーティングシステム１２００が管轄するコアに復帰させる。

　ステップＳ１３０６において、ベアメタル構築部１２４３は、ステップＳ１３０３で必要な数のコアに対してベアメタル環境を構築していないと判定した場合、後述するベアメタル構築レイテンシテーブル１２４４からベアメタル環境構築に係る一連のオペレーションのオーバヘッド時間を取得する。

　ステップＳ１３０７において、ベアメタル構築部１２４３は、ステップＳ１３０６で取得したオーバヘッド時間の合計値が、該当処理ブロックの次の周期の開始時刻に間に合うか否かを判定する。該当処理ブロックの次の周期の開始時刻に間に合う場合は、ステップＳ１３０８に移行する。一方、該当処理ブロックの次の周期の開始時刻に間に合わない場合は、ステップＳ１３０９に移行する。

　ステップＳ１３０８において、ベアメタル構築部１２４３は、オペレーティングシステム１２００のＨｏｔｐｌｕｇ機能を使用して、必要な数のコアを論理オフとする。

　ステップＳ１３０９において、ベアメタル構築部１２４３は、次の周期はＯＳ環境で実行し、その次の周期で必要な数のコアを論理オフとする。なお、ベアメタル環境を構築する対象のコアは、演算装置１００１が備えるプロセッサコア１１００－１～１１００―４のいずれかであり、オペレーティングシステム１２００によって論理オフされていないコアである。

　図１０は、ベアメタル構築レイテンシテーブル１２４４の一例を示す図である。

　ベアメタル構築レイテンシテーブル１２４４は、ベアメタル環境の構築に係るオペレーションごとにオーバヘッド時間（所要時間）を保持している。オペレーションのオーバヘッド時間は、準備段階時に計測し、ベアメタル構築レイテンシテーブル１２４４に反映する。なお、図１０に記載の各オペレーションのオーバヘッド時間は参考値である。

　図１１は、ベアメタルローダ部１２４５の動作の一例を示すフローチャートである。

　ステップＳ１４０１において、ベアメタルローダ部１２４５は、該当処理ブロックがベアメタル環境での実行が必要であると判定されたか否かを確認する。該当処理ブロックがベアメタル環境での実行が必要である場合は、ステップＳ１４０２に移行する。一方、該当処理ブロックがベアメタル環境での実行が必要でない場合は、ステップＳ１４０４に移行する。

　ステップＳ１４０２において、ベアメタルローダ部１２４５は、該当処理ブロックのベアメタル環境用実行バイナリを、演算装置１００１が備える図示しない主記憶装置上のロード先の仮想アドレスに展開する。なお、ロード先の仮想アドレスは、事前にユーザによって指定されていることを前提とする。

　ステップＳ１４０３において、ベアメタルローダ部１２４５は、ベアメタル環境のコアのプログラムカウンタに該当処理ブロックの仮想アドレス（エントリポイント）を設定し、ＲＵＮＮＩＮＧ状態とする。

　なお、各コアのプログラムカウンタを含むレジスタ情報は、例えば、Ｌｉｎｕｘの場合はデバイスツリーから取得することができる。また、ＲＵＮＮＩＮＧ状態とされた該当処理ブロックは、後述する関数テーブル１３３０のポーリング関数を使用することによって、起動を知らせる割込み要求をポーリングし、割込み要求を検知したら処理を実行させる。

　ステップＳ１４０４において、ベアメタルローダ部１２４５は、該当処理ブロックのＯＳ環境用実行バイナリをオペレーティングシステム１２００が有するスケジューラで実行する。

　図１２は、ベアメタル連携部１２４６の動作の一例を示すフローチャートである。

　ステップＳ１５０１において、ベアメタル連携部１２４６は、ベアメタル環境用実行バイナリを起動するための割込み要求を検知したか否かを判定する。ベアメタル環境用実行バイナリを起動するための割込み要求を検知した場合は、ステップＳ１５０２に移行する。一方、ベアメタル環境用実行バイナリを起動するための割込み要求を検知していない場合は、図１２の動作を終了する。

　ステップＳ１５０２において、ベアメタル連携部１２４６は、実行アドレスに基づいて、ＯＳ環境での該当処理ブロックの起動を中止する。

　ステップＳ１５０３において、ベアメタル連携部１２４６は、該当処理ブロックがベアメタル環境で実行されて、実行完了を知らせるための割込み要求を検知するまで待機する。

　ステップＳ１５０４において、ベアメタル連携部１２４６は、ステップＳ１５０３で割込み要求を検知したら、該当処理ブロックが先行処理ブロックとなっている処理ブロック（つまり、後行処理ブロック）を起動する。

　図１３は、演算アプリ生成部１３１０の動作の一例を示すフローチャートである。

　ステップＳ１６０１において、演算アプリ生成部１３１０は、演算アプリ本体コード１３２０に後述する関数テーブル１３３０内のＯＳ環境用関数を挿入して、ＯＳ環境用の演算アプリ合成コード１３４０を生成する。

　ステップＳ１６０２において、演算アプリ生成部１３１０は、ＯＳ環境用の演算アプリ合成コード１３４０をＯＳ用コンパイラ（例えば、ＧＣＣ（GNU Compiler Collection（登録商標））でコンパイルして、ＯＳ環境用実行バイナリを生成する。

　ステップＳ１６０３において、演算アプリ生成部１３１０は、演算アプリ本体コード１３２０に関数テーブル１３３０内のベアメタル環境用関数を挿入して、ベアメタル環境用の演算アプリ合成コード１３４０を生成する。

　ステップＳ１６０４において、演算アプリ生成部１３１０は、ベアメタル環境用の演算アプリ合成コード１３４０をベアメタル用コンパイラでコンパイルし、ロード先の仮想アドレスを指定してベアメタル環境用実行バイナリを生成する。ロード先の仮想アドレスは、ユーザが事前に決定し、ベアメタル環境用実行バイナリをロードした後に関数テーブル１３３０のメモリのロック関数を使用して、このロード先仮想アドレスから始まる任意のサイズの領域をスワップアウトされない領域として確保する。これにより、ベアメタル環境で動作するアプリケーションは、その実行時にスワップアウトによるジッタが入ることを防ぐ効果がある。

　図１４は、関数テーブル１３３０の一例を示す図である。

　演算アプリ本体コード１３２０に対して、関数テーブル１３３０に記載された各関数を挿入することによって、ＯＳ環境用実行バイナリとベアメタル環境用実行バイナリとを連携させて動作させることが可能となる。

　ベアメタル環境用実行バイナリは、仮想アドレス空間上の事前にユーザによって決められたサイズの領域に展開されることを想定している。通常、主記憶装置の物理アドレス空間が使い果たされると、ＯＳのメモリ管理によってスワップアウトが発生し、ジッタが発生する可能性がある。そのため、ベアメタル環境用実行バイナリに用いる領域は、スワップアウトされないようにメモリをロックする。これを実現する関数が、関数テーブル１３３０におけるメモリのロック関数、およびメモリのロック解除関数であり、例えば、Ｌｉｎｕｘを用いる場合は、ｍｌｏｃｋ（ ）およびｍｕｎｌｏｃｋ（ ）の２つのシステムコールを使用する。

　ＯＳ環境用バイナリおよびベアメタル環境用実行バイナリに含まれる、互いに依存関係のある処理ブロック間でデータ通信を行うために、共有メモリ領域を設定して両方の実行バイナリからの読み書きを可能とする。これを実現する関数が、関数テーブル１３３０における共有メモリの確保関数、共有メモリの解放関数、共有メモリへのデータ書込み関数、および共有メモリからのデータ読込み関数である。

　ＯＳ環境用バイナリおよびベアメタル環境用実行バイナリに含まれる、互いに依存関係のある処理ブロックの実行制御については、コア間の割込みを利用する。ＯＳ環境コア（ＯＳ環境が構築されたコア）からベアメタル環境コア（ベアメタル環境が構築されたコア）に該当処理ブロックの起動を知らせる割込み要求（起動通知）を送信し、ベアメタル環境コアで受信する。ベアメタル環境コアでは、該当処理ブロックが割込み要求をポーリングし、当該割込み要求を検知したら処理を実行する。ベアメタル環境コアは、該当処理ブロックの処理が完了したら、ベアメタル環境コアからＯＳ環境コアに完了を知らせる割込み要求（完了通知）を送信し、当該割込み要求をＯＳ環境コアが受信する。これを実現する関数が、関数テーブル１３３０における割込み要求の送信関数、割込み要求の受信関数、およびポーリング関数である。

　＜実施の形態１の効果＞
　実施の形態１では、処理ブロックの処理時間の経時的な変化と、ＯＳジッタの統計情報の経時的な変化とを監視し、ユーザが定義したベアメタル要否判定テーブル１２４１に基づいて、動的に処理ブロックをベアメタル環境で実行する。これにより、アプリケーションの実行状況に応じて、ＯＳジッタを削減することができる。

　＜実施の形態２＞
　図１５は、実施の形態２による情報処理装置２０００の構成の一例を示すブロック図である。

　情報処理装置２０００は、演算装置１００１および記憶装置２００２を備えており、記憶装置２００２がオペレーティングシステム２２００を備えることを特徴としている。具体的には、ＯＳジッタ同定部２２１０がキャッシュ統計情報取得部２２１１およびキャッシュ統計情報テーブル２２１２を備え、ベアメタル制御部２２２０がベアメタル要否判定テーブル２２２１およびベアメタル要否判定部２２２２を備えていることを特徴としている。その他の構成および動作は、実施の形態１による情報処理装置１０００と同様であるため、ここでは詳細な説明を省略する。

　キャッシュ統計情報取得部２２１１は、キャッシュメモリに関する統計情報を取得する。なお、キャッシュメモリは、演算装置１００１が備えているものとする。

　キャッシュ統計情報テーブル２２１２は、キャッシュメモリのモニタリングする項目ごとに、数値範囲とそれに対応するレベル（キャッシュ性能レベル）が、ユーザによって設定される。

　図１６は、キャッシュ統計情報テーブル２２１２の一例を示す図である。

　処理ブロックの処理時間が変動する主な要因として、キャッシュメモリにヒットするか否かが挙げられる。情報処理装置２０００における演算装置１００１は、キャッシュメモリを備えていることを想定している。情報処理装置２０００において実行されるアプリケーションの数が多くなる程キャッシュミス率が高くなり、キャッシュにヒットしないことによって、同じ演算負荷であっても処理時間に差異が生じる。従って、キャッシュ統計情報を把握することは、アプリケーションの実行状況を把握するために重要である。

　図１６に示すキャッシュ統計情報テーブル２２１２は、図３に示すＯＳジッタ統計情報テーブル１２１２と同じ体裁である。ユーザは、準備段階時に、キャッシュに関するモニタリング項目、その数値範囲、およびキャッシュ性能レベルを設定する。なお、図１６の例では、Ｌ１キャッシュミス率およびＬ２キャッシュミス率をモニタリング項目としているが、これらに限定されるものではない。また、キャッシュ性能レベルを「低」、「中」、および「高」の３段階設定しているが、これに限定されるものではない。

　キャッシュ統計情報は、ＣＰＵベンダーによって提供されているＰＭＵ（Performance Monitoring Unit）を使用して取得しても良く、汎用ＯＳが提供する性能解析ツール（例えば、Ｌｉｎｕｘにおけるｐｅｒｆ）を使用して取得しても良い。この処理は、キャッシュ統計情報取得部２２１１によって行われる。

　図１７は、ベアメタル要否判定テーブル２２２１の一例を示す図である。

　図１７に示すベアメタル要否判定テーブル２２２１は、図７に示すベアメタル要否判定テーブル１２４１と同じ体裁である。ＯＳジッタ統計情報テーブル１２１２で設定したＯＳジッタの種類と、演算負荷テーブル１２２２で設定した演算負荷以外に、キャッシュ統計情報テーブル２２１２で設定したキャッシュ性能をベアメタル実行条件に設定する。

　図１７の例では、処理ブロックＡについて、演算負荷およびキャッシュ性能のそれぞれのレベルをＡＮＤ条件として「条件１」に設定し、カーネル処理およびＩＯ処理のそれぞれのレベルをＡＮＤ条件として「条件２」に設定し、「条件１」および「条件２」はＯＲ条件としている。なお、キャッシュ性能についても、該当処理ブロックがベアメタル環境での実行が必要と判断するのに必要な場合にのみ設定すれば良い。

　図１８は、ベアメタル要否判定部２２２２の動作の一例を示すフローチャートである。図１８のステップＳ２００１、ステップＳ２００３、ステップＳ２００５、およびステップＳ２００６は、図８のステップＳ１２０１～ステップＳ１２０５と同様であるため、ここでは説明を省略する。いかでは、ステップＳ２００２およびステップＳ２００４について説明する。なお、ベアメタル要否判定の処理は、該当処理ブロックの先行処理ブロックの実行時に行うことを想定している。

　ステップＳ２００２において、ベアメタル要否判定部２２２２は、キャッシュ統計情報取得部２２１１から現在のキャッシュ統計情報を取得し、キャッシュ統計情報テーブル２２１２に問い合わせて、対応するキャッシュ性能レベルを取得する。

　ステップＳ２００４において、ベアメタル要否判定部２２２２は、現在のＯＳジッタレベル、キャッシュシ性能レベル、および演算負荷レベルをベアメタル要否判定テーブル２２２１に問い合わせて、現在のＯＳジッタレベル、キャッシュシ性能レベル、および演算負荷レベルが該当処理ブロックのベアメタル実行条件に当てはまるか否かを確認する。

　＜実施の形態２の効果＞
　実施の形態２では、処理ブロックの処理時間に影響するキャッシュメモリに関する統計情報（キャッシュ統計情報）を取得し、キャッシュ統計情報に基づいたベアメタル環境での実行が必要か否かを判定する。これにより、より精緻にアプリケーションの実行状況に応じてＯＳジッタを削減することが可能となる。

　＜実施の形態３＞
　図１９は、情報処理装置３０００の構成の一例を示すブロック図である。

　情報処理装置３０００は、演算装置１００１および記憶装置３００２を備えており、記憶装置３００２がオペレーティングシステム３２００を備えることを特徴としている。具体的には、演算負荷同定部３２１０が演算負荷学習部３２１１、演算負荷モデル記憶部３２１２、および演算負荷推定部３２１３を備えていることを特徴としている。その他の構成および動作は、実施の形態１による情報処理装置１０００と同様であるため、ここでは詳細な説明を省略する。

　演算負荷学習部３２１１は、処理ブロックの処理時間を計測し、取得した入力値に対する処理時間の傾向を学習する。演算負荷学習部３２１１が学習したモデルは、演算負荷モデル記憶部３２１２に記憶される。演算負荷推定部３２１３は、新たに取得した入力値と学習したモデルとから処理時間を推定し、演算負荷テーブル１２２２を参照して演算負荷レベルを同定する。

　図２０は、演算負荷学習部３２１１の動作の一例を示すフローチャートである。

　ステップＳ３００１において、演算負荷学習部３２１１は、入力値取得部１２２１から、該当処理ブロックの入力値を取得する。

　ステップＳ３００２において、演算負荷学習部３２１１は、該当処理ブロックの実行アドレスに基づいて、該当処理ブロックの処理時間を計測する。

　ステップＳ３００３において、演算負荷学習部３２１１は、十分なサンプル数が得られたか否かを判定する。ここで、十分なサンプル数とは、例えば、ユーザが事前に定義しておいても良い。十分なサンプル数が得られた場合は、ステップＳ３００４に移行する。一方、十分なサンプル数が得られていない場合は、ステップＳ３００１に戻る。

　ステップＳ３００４において、演算負荷学習部３２１１は、該当処理ブロックの入力値に対する処理時間の傾向を学習し、モデルを作成する。

　ステップＳ３００５において、演算負荷学習部３２１１は、作成したモデルを演算負荷モデル記憶部３２１２に記憶する。モデルの学習には、例えば、ＲＮＮ（Recurrent Neural Network）を用いて、連続した複数周期で取得した入力値の系列データから、計測した処理時間を推定するように学習する。なお、学習に使用するアルゴリズムは、ＲＮＮに限定されるものではない。また、入力値に対する処理時間の学習は、運用段階時に行っても良い。例えば、演算アプリの機能がアップデートされると、同じ入力値であっても、内部処理が変更されたことによって演算負荷が変わるケースが考えられる。

　図２１は、演算負荷推定部３２１３の動作の一例を示すフローチャートである。

　ステップＳ３１０１において、演算負荷推定部３２１３は、入力値取得部１２２１から該当処理ブロックの入力値を取得する。

　ステップＳ３１０２において、演算負荷推定部３２１３は、演算負荷モデル記憶部３２１２に記憶したモデルに基づいて、取得した入力値に対する処理時間を推定する。

　ステップＳ３１０３において、演算負荷推定部３２１３は、推定した処理時間を演算負荷テーブル１２２２に問い合わせ、対応する演算負荷レベルを同定する。

　＜実施の形態３の効果＞
　実施の形態３では、処理ブロックの入力値に対する演算負荷を学習および推論する。これにより、運用段階で演算アプリに機能等の変更があった場合でも、容易に演算負荷を同定する事が可能となる。

　なお、本開示の範囲内において、各実施の形態を自由に組み合わせたり、各実施の形態を適宜、変形、省略したりすることが可能である。

　本開示は詳細に説明されたが、上記した説明は、すべての態様において、例示であって、限定的なものではない。例示されていない無数の変形例が想定され得るものと解される。

　１０００　情報処理装置、１００１　演算装置、１００２　記憶装置、１００３　ＮＷ装置、１００４　ＩＯ装置、１００５　ネットワーク、１１００　プロセッサ、１１００－１～１１００－４　プロセッサコア、１２００　オペレーティングシステム、１２１０　ＯＳジッタ同定部、１２１１　ＯＳジッタ統計情報取得部、１２１２　ＯＳジッタ統計情報テーブル、１２１２－１　カーネル処理、１２１２－２　ＩＯ処理、１２１２－３　メモリ管理、１２２０　演算負荷同定部、１２２１　入力値取得部、１２２２　演算負荷テーブル、１２２２－１～１２２２－３　テーブル、１２３０　テーブル設定Ｉ／Ｆ、１２４０　ベアメタル制御部、１２４１　ベアメタル要否判定テーブル、１２４２　ベアメタル要否判定部、１２４３　ベアメタル構築部、１２４４　ベアメタル構築レイテンシテーブル、１２４５　ベアメタルローダ部、１２４６　ベアメタル連携部、１３００　コンパイラ部、１３１０　演算アプリ生成部、１３２０　演算アプリ本体コード、１３３０　関数テーブル、１３４０　演算アプリ合成コード、２０００　情報処理装置、２００２　記憶装置、２２００　オペレーティングシステム、２２１０　ＯＳジッタ同定部、２２１１　キャッシュ統計情報取得部、２２１２　キャッシュ統計情報テーブル、２２２０　ベアメタル制御部、２２２１　ベアメタル要否判定テーブル、２２２２　ベアメタル要否判定部、３０００　情報処理装置、３００２　記憶装置、３２００　オペレーティングシステム、３２１０　演算負荷同定部、３２１１　演算負荷学習部、３２１２　演算負荷モデル記憶部、３２１３　演算負荷推定部。

Claims (7)

1. 　複数のプロセッサコアを含む演算装置と、
   　前記演算装置で実行されるオペレーティングシステムと、
   　を備え、アプリケーションを実行する情報処理装置であって、
   　前記オペレーティングシステムは、
   　前記オペレーティングシステムの処理において発生するＯＳジッタの統計情報であるＯＳジッタ統計情報を取得するＯＳジッタ統計情報取得部と、
   　前記ＯＳジッタ統計情報に対応付けられたＯＳジッタのレベルであるＯＳジッタレベルが規定されたＯＳジッタ統計情報テーブルと、
   　前記アプリケーションの入力値を取得する入力値取得部と、
   　前記入力値に対応付けられた、前記アプリケーションを構成する処理ブロックの演算負荷のレベルである演算負荷レベルが規定された演算負荷テーブルと、
   　前記ＯＳジッタレベルおよび前記演算負荷レベルに基づいて、前記処理ブロックを前記オペレーティングシステムが実行されないベアメタル環境で実行する必要があるか否かを判定するベアメタル要否判定部と、
   を備える、情報処理装置。
2. 　前記オペレーティングシステムは、
   　テーブル設定Ｉ／Ｆと、
   　前記ＯＳジッタレベルおよび前記演算負荷レベルを用いて、前記処理ブロックを前記ベアメタル環境で実行するために必要な条件であるベアメタル実行条件が規定されたベアメタル要否判定テーブルと、
   　前記ベアメタル環境となっていない前記プロセッサコアに対して前記ベアメタル環境を構築するベアメタル構築部と、
   をさらに備え、
   　前記ベアメタル実行条件は、前記テーブル設定Ｉ／Ｆを介してユーザによって設定され、
   　前記ベアメタル要否判定部は、前記ＯＳジッタレベルおよび前記演算負荷レベルが前記ベアメタル実行条件に合致したとき、前記処理ブロックを前記ベアメタル環境で実行する必要があると判定する、請求項１に記載の情報処理装置。
3. 　前記オペレーティングシステムは、
   　前記ベアメタル環境となっていない前記プロセッサコアに対して前記ベアメタル環境を構築するベアメタル構築部と、
   　前記ベアメタル環境の構築に要するオーバヘッド時間を保持するベアメタル構築レイテンシテーブルと、
   をさらに備え、
   　前記ベアメタル構築部は、前記オーバヘッド時間に基づいて、前記処理ブロックの開始時刻に間に合う場合は前記ベアメタル環境を構築する、請求項１に記載の情報処理装置。
4. 　前記アプリケーションの本体コードである演算アプリ本体コードと、関数テーブルとに基づいて、前記オペレーティングシステムが実行されるオペレーティングシステム環境で実行可能なオペレーティングシステム環境用実行バイナリと、前記ベアメタル環境で実行可能なベアメタル環境用実行バイナリとを生成する演算アプリ生成部をさらに備え、
   　前記オペレーティングシステム環境用実行バイナリおよび前記ベアメタル環境用実行バイナリのそれぞれに含まれる互いに依存関係になる前記処理ブロック間で、起動通知または完了通知を送受信する、請求項１から３のいずれか１項に記載の情報処理装置。
5. 　主記憶装置と、
   　前記ベアメタル環境用実行バイナリを前記主記憶装置の予め定められた仮想アドレスに展開し、前記ベアメタル環境の前記プロセッサコアのプログラムカウンタに、前記ベアメタル環境用実行バイナリに含まれる実行対象の前記処理ブロックのエントリポイントを設定するベアメタルローダ部と、
   　前記オペレーティングシステム環境用実行バイナリから前記ベアメタル環境用実行バイナリに対して送信される前記起動通知に基づいて、前記処理ブロックを前記オペレーティングシステムで実行されないように制御し、前記ベアメタル環境用実行バイナリから前記オペレーティングシステム環境用実行バイナリに対して送信される前記完了通知に基づいて、前記処理ブロックの後に実行される処理ブロックを前記オペレーティングシステムで実行されるように制御するベアメタル連携部と、
   を備える、請求項４に記載の情報処理装置。
6. 　前記演算装置は、キャッシュメモリをさらに備え、
   　前記オペレーティングシステムは、
   　前記キャッシュメモリに関する統計情報であるキャッシュ統計情報を取得するキャッシュ統計情報取得部と、
   　前記キャッシュ統計情報に対応付けられたキャッシュ性能のレベルであるキャッシュ性能レベルが規定されたキャッシュ統計情報テーブルと、
   をさらに備え、
   　前記ベアメタル要否判定テーブルでは、前記ＯＳジッタレベル、前記演算負荷レベル、および前記キャッシュ性能を用いて前記ベアメタル実行条件が規定され、
   　前記ベアメタル要否判定部は、前記ＯＳジッタレベル、前記演算負荷レベル、および前記キャッシュ性能レベルが前記ベアメタル実行条件に合致したとき、前記処理ブロックを前記ベアメタル環境で実行する必要があると判定する、請求項２に記載の情報処理装置。
7. 　前記オペレーティングシステムは、
   　前記入力値取得部が取得した前記入力値に対する前記処理ブロックの演算負荷を学習して演算負荷モデルを生成する演算負荷学習部と、
   　前記入力値取得部が取得した前記入力値と、前記演算負荷モデルとに基づいて、前記処理ブロックの演算負荷を推定する演算負荷推定部と、
   をさらに備える、請求項１または２に記載の情報処理装置。

Images