JP2018508886A - マルチプロセッサシステムにおける揮発性メモリ保守イベントのスケジューリング - Google Patents

マルチプロセッサシステムにおける揮発性メモリ保守イベントのスケジューリング Download PDF

Info

Publication number
JP2018508886A
JP2018508886A JP2017541063A JP2017541063A JP2018508886A JP 2018508886 A JP2018508886 A JP 2018508886A JP 2017541063 A JP2017541063 A JP 2017541063A JP 2017541063 A JP2017541063 A JP 2017541063A JP 2018508886 A JP2018508886 A JP 2018508886A
Authority
JP
Japan
Prior art keywords
processor
priority
maintenance event
processors
dram
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
Application number
JP2017541063A
Other languages
English (en)
Inventor
デクスター・タミオ・チュン
ヤンル・リ
リチャード・アラン・スチュアート
サブラト・クマール・デ
Original Assignee
クアルコム，インコーポレイテッド
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by クアルコム，インコーポレイテッド filed Critical クアルコム，インコーポレイテッド
Publication of JP2018508886A publication Critical patent/JP2018508886A/ja
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G06F13/16—Handling requests for interconnection or transfer for access to memory bus
    • G06F13/1605—Handling requests for interconnection or transfer for access to memory bus based on arbitration
    • G06F13/161—Handling requests for interconnection or transfer for access to memory bus based on arbitration with latency improvement
    • G06F13/1636—Handling requests for interconnection or transfer for access to memory bus based on arbitration with latency improvement using refresh
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G06F13/20—Handling requests for interconnection or transfer for access to input/output bus
    • G06F13/24—Handling requests for interconnection or transfer for access to input/output bus using interrupt
    • G06F13/26—Handling requests for interconnection or transfer for access to input/output bus using interrupt with priority control
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G06F13/16—Handling requests for interconnection or transfer for access to memory bus
    • G06F13/18—Handling requests for interconnection or transfer for access to memory bus based on priority control
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G06F13/16—Handling requests for interconnection or transfer for access to memory bus
    • G06F13/1605—Handling requests for interconnection or transfer for access to memory bus based on arbitration
    • G06F13/1652—Handling requests for interconnection or transfer for access to memory bus based on arbitration in a multiprocessor architecture
    • G06F13/1663—Access to shared memory

Abstract

揮発性メモリ保守イベントをスケジューリングするためのシステム、方法、およびコンピュータプログラムを開示する。一実施形態は、メモリデータインターフェースを介してメモリコントローラに結合される揮発性メモリデバイスに対して保守イベントを実行するためにメモリコントローラがタイムオブサービス(ToS)ウィンドウを決定するステップと、保守イベントをスケジュールするためにメモリコントローラがシステムオンチップ(SoC)上の複数のプロセッサの各々に信号を提供するステップと、信号に応答して複数のプロセッサの各々が独立して保守イベントのための対応するスケジュール通知を生成するステップと、複数のプロセッサによって生成されたスケジュール通知のうちの1つまたは複数を受信することに応答して、およびプロセッサ優先順位方式に基づいて、メモリコントローラが保守イベントをいつ実行するかを決定するステップとを含む方法である。

Description

本出願は、マルチプロセッサシステムにおける揮発性メモリ保守イベントのスケジューリングに関する。
ポータブルコンピューティングデバイス(たとえば、セルラー電話、スマートフォン、タブレットコンピュータ、携帯情報端末(PDA)、および携帯ゲーム機)および他のコンピューティングデバイスは、ますます拡大する数々の機能およびサービスを提供し続けており、ユーザには情報、リソース、および通信へのかつてないレベルのアクセスが提供されている。これらのサービス拡張とペースを合わせるために、そのようなデバイスは、より強力、かつより複雑になってきた。ここで、ポータブルコンピューティングデバイスには、一般に、単一の基板上に組み込まれた1つまたは複数のチップ構成要素(たとえば、1つまたは複数の中央処理ユニット(CPU)、グラフィックス処理ユニット(GPU)、デジタル信号プロセッサなど)を含む、システムオンチップ(SoC)が含まれる。SoCは、高性能データおよび制御インターフェースを介して、ダイナミックランダムアクセスメモリ(DRAM)などの、1つまたは複数の揮発性メモリデバイスに結合されてもよい。
高性能DRAMメモリは、一般に、様々なタイプのハードウェア保守イベントが実行されることを必要とする。たとえば、比較的高いクロック周波数(たとえば、GHzクロック周波数)においてインターフェースのエラーのない動作を提供するために、定期的な較正およびトレーニングが実行される場合がある。メモリデータの各ビットは、チップ上の小型キャパシタに電荷の有無として記憶されるので、メモリリフレッシュが、DRAMメモリの動作中に必要とされるバックグラウンド保守プロセスである。時間の経過とともに、メモリセル内の電荷は漏出し、したがってリフレッシュされることがなければ、記憶されたデータは最終的に失われることになる。これを防止するために、DRAMコントローラが、定期的に各セルを読み出し、これを再書き込みし、キャパシタ上の電荷をその元のレベルに戻す。
これらのハードウェア保守イベントは、CPUトラフィックを望ましくなく遮る場合がある。たとえば、既存のシステムでは、ハードウェア保守イベントは、メモリコントローラによって制御される独立したイベントであり、これらはアクティブCPUプロセスとこれらの定期的な独立したDRAMハードウェアイベントとの間でメモリアクセス衝突を生じる可能性がある。衝突が発生するとき、CPUプロセスは、DRAMハードウェアイベントがサービスされている(service)間、一時的にストールする場合がある。DRAMにサービスすることはまた、CPUプロセスが使用している、開いているページを、閉じるまたはリセットする場合もある。CPUプロセスをストールすることは望ましくなく、したがって、DRAMハードウェアイベントは、一般的には個々に行われる。SoCハードウェアは、DRAMハードウェアイベントを延期する能力を有する場合があるが、それは一般的には非常に短い時間期間(たとえば、ナノ秒レベル)の間だけである。その結果、アクティブCPUプロセスは、多数の個々のDRAMハードウェアイベントによって引き起こされる確率的ブロキングによる望ましくない非効率を招く場合がある。
したがって、定期的な揮発性メモリ保守イベントによって引き起こされるメモリアクセス衝突を減少させ、CPUプロセスメモリ効率を向上させるためのシステムおよび方法を提供する必要がある。
揮発性メモリ保守イベントをスケジューリングするためのシステム、方法、およびコンピュータプログラムを開示する。一実施形態は、メモリデータインターフェースを介してメモリコントローラに結合される揮発性メモリデバイスに対して保守イベントを実行するためにメモリコントローラがタイムオブサービス(ToS)ウィンドウを決定するステップと、保守イベントをスケジュールするためにメモリコントローラがシステムオンチップ(SoC)上の複数のプロセッサの各々に信号を提供するステップと、信号に応答して複数のプロセッサの各々が独立して保守イベントのための対応するスケジュール通知を生成するステップと、複数のプロセッサによって生成されたスケジュール通知のうちの1つまたは複数を受信することに応答して、およびプロセッサ優先順位方式に基づいて、メモリコントローラが保守イベントをいつ実行するかを決定するステップとを含む方法である。
別の実施形態は、揮発性メモリ保守イベントをスケジュールするためのシステムである。システムは、ダイナミックランダムアクセスメモリ(DRAM)デバイスと、システムオンチップ(SoC)とを含む。SoCは、複数のプロセッサと、メモリデータインターフェースを介してDRAMデバイスに電気的に結合されるDRAMコントローラとを含む。DRAMコントローラは、DRAMデバイスに対して保守イベントを実行するためにタイムオブサービス(ToS)ウィンドウを決定することであって、ToSウィンドウが、複数のプロセッサの各々に提供される信号、および保守イベントを実行するためのデッドラインによって定義される、タイムオブサービス(ToS)ウィンドウを決定することと、信号に応答して、およびプロセッサ優先順位方式に基づいて、複数のプロセッサによって独立して生成されたスケジュール通知を受信することに応答して、保守イベントをいつ実行するかを決定することとを行うように構成される論理を含む。
図の中では、別段に示されていない限り、様々な図の全体を通して、同様の参照番号は同様の部分を指す。"102A"または"102B"などの文字指定を伴う参照番号の場合、文字指定は、同じ図に存在している2つの同様の部分または要素を区別することができる。参照番号がすべての図において同じ参照番号を有するすべての部分を含むことが意図されるとき、参照番号に対する文字指定は省略される場合がある。
揮発性メモリ保守イベントをスケジュールするためのシステムの一実施形態のブロック図である。 図1のシステムの構成要素および動作を示すブロック/流れ図である。 図1および図2のシステム内でDRAM保守イベントをスケジュールするための方法の一実施形態を示すフローチャートである。 DRAM保守イベントをスケジュールするためのタイムオブサービス(ToS)ウィンドウを示すタイムラインである。 優先順位表に従って、CPUスレッドA、B、およびC、ならびにDRAM保守イベントをスケジュールするためのシステムの別の実施形態を示すブロック/流れ図である。 カーネルスケジューラを介してスケジュールせずに、図5のシステム内でDRAM保守イベントを定期的に実行するための方法の一実施形態を示すタイムラインである。 優先順位表に従ってDRAM保守イベントをスケジュールするための方法の一実施形態を示すタイムラインである。 優先順位表に従ってDRAM保守イベントをスケジュールするためのシステムの別の実施形態を示すブロック/流れ図である。 DRAM保守イベントをスケジュールするための優先順位表を生成するための方法の一実施形態を示すフローチャートである。 DRAM保守イベントの優先順位を決定するための優先順位表の例示的な実施形態を示す図である。 ToSウィンドウの間に実行されるDRAMリフレッシュイベントを示すタイムラインである。 ToSウィンドウが終了した後にDRAMリフレッシュイベントを実行するためのハードウェア介入方法の一実施形態を示すタイムラインである。 DRAM保守イベントをスケジュールするためのシステムおよび方法を組み込む場合があるポータブルコンピューティングデバイスの一実施形態のブロック図である。 マルチプロセッサSoCに揮発性メモリ保守イベントをスケジュールするためのシステムの別の実施形態のブロック図である。 図14のDRAMコントローラ内の決定モジュールの一実施形態を示す、組み合わされた流れ/ブロック図である。 図14のマルチプロセッサSoC内でDRAM保守イベントをスケジュールするための方法の一実施形態を示すフローチャートである。 図14のマルチプロセッサSoC内でDRAM保守イベントを独立してスケジュールおよび制御するための方法の一実施形態を示すタイムラインである。 図15の決定優先順位表の一実施形態を示す表である。 図14のプロセッサの各々によって独立して生成される通知の例示的な実装形態を示すデータ図である。
「例示的」という語は、本明細書では「例、事例、または例示としての役割を果たすこと」を意味するために使用される。「例示的」として本明細書において説明されるいずれの態様も、必ずしも他の態様よりも好ましいか、または有利であると解釈されるべきでない。
本明細書では、「アプリケーション」または「イメージ」という用語は、オブジェクトコード、スクリプト、バイトコード、マークアップ言語ファイル、およびパッチなどの、実行可能なコンテンツを有するファイルを含む場合もある。加えて、本明細書で参照される「アプリケーション」は、オープンされる必要があり得るドキュメントまたはアクセスされる必要がある他のデータファイルなどの、本質的に実行可能でないファイルを含む場合もある。
「コンテンツ」という用語は、オブジェクトコード、スクリプト、バイトコード、マークアップ言語ファイル、およびパッチなどの、実行可能コンテンツを有するファイルを含む場合もある。加えて、本明細書で参照される「コンテンツ」は、オープンされる必要があり得る文書またはアクセスされる必要がある他のデータファイルなどの、本質的に実行可能でないファイルを含む場合もある。
「構成要素」、「データベース」、「モジュール」、「システム」などの用語は、本明細書で使用されるとき、ハードウェア、ファームウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、または実行中のソフトウェアのいずれかであるコンピュータ関連エンティティを指すものとする。たとえば、構成要素は、限定はしないが、プロセッサ上で実行されているプロセス、プロセッサ、オブジェクト、実行可能ファイル、実行のスレッド、プログラム、および/またはコンピュータであってもよい。例として、コンピューティングデバイス上で実行されるアプリケーションとコンピューティングデバイスの両方が構成要素であってもよい。1つまたは複数の構成要素は、プロセスおよび/または実行のスレッド内に存在してもよく、構成要素は、1つのコンピュータ上に局在化されてもよく、および/または2つ以上のコンピュータ間に分散されてもよい。さらに、これらの構成要素は、様々なデータ構造を記憶した様々なコンピュータ可読媒体から実行されてもよい。構成要素は、1つまたは複数のデータパケット(たとえば、ローカルシステム、分散システム内の別の構成要素と、および/またはインターネットなどのネットワークにわたって他のシステムと信号により対話する、1つの構成要素からのデータ)を有する信号に従って、ローカルプロセスおよび/またはリモートプロセスによって通信してもよい。
この説明において、「通信デバイス」、「ワイヤレスデバイス」、「ワイヤレス電話」、「ワイヤレス通信デバイス」、および「ワイヤレスハンドセット」という用語は、互換的に使用される。第3世代("3G")ワイヤレス技術および第4世代("4G")が出現したことによって、利用可能な帯域幅が拡大されたので、より多様なワイヤレス能力を備えた、より持ち運びしやすいコンピューティングデバイスが可能になった。したがって、ポータブルコンピューティングデバイスには、セルラー電話、ページャ、PDA、スマートフォン、ナビゲーションデバイス、またはワイヤレス接続もしくはワイヤレスリンクを有するハンドヘルドコンピュータが含まれる場合がある。
図1は、メモリコントローラを介して揮発性メモリハードウェア保守イベントのカーネルスケジューリングを提供するためのシステム100の一実施形態を示す。システム100は、パーソナルコンピュータと、ワークステーションと、サーバと、セルラー電話、携帯情報端末(PDA)、ポータブルゲームコンソール、またはタブレットコンピュータなどのポータブルコンピューティングデバイス(PCD)とを含む、任意のコンピューティングデバイスに実装される場合がある。システム100は、1つまたは複数のメモリデバイスに電気的に結合されるシステムオンチップ(SoC)102を含む。メモリデバイスは、揮発性メモリ(たとえば、ダイナミックランダムアクセスメモリ(DRAM)104)と、不揮発性メモリ118とを含んでもよい。DRAM104は、高性能データバス107および制御バス105を介してSoC102に電気的に結合されてもよい。
SoC102は、様々なオンチップまたはオンダイ構成要素を含む。図1の実施形態では、SoC102は、SoCバス116を介して相互接続された、1つまたは複数の処理デバイス(たとえば、中央処理装置(CPU)106、グラフィックス処理装置(GPU)、デジタル信号プロセッサ(DSP)など)と、DRAMコントローラ108と、スタティックランダムアクセスメモリ(SRAM)110と、読取り専用メモリ(ROM)112と、ストレージコントローラ114とを含む。ストレージコントローラ114は、不揮発性メモリ118に結合され、関連するメモリトランザクションを制御する。不揮発性メモリ118は、たとえば、フラッシュメモリ、フラッシュドライブ、セキュアデジタル(SD)カード、ソリッドステートドライブ(SSD)、または他のタイプなど、任意の不揮発性メモリを含む場合があることを諒解されたい。CPU106は、現在のCPU処理負荷を決定するための1つまたは複数のセンサ126を含んでもよい。DRAM104は、DRAM104の温度を決定するための1つまたは複数の温度センサ128を含んでもよい。
DRAMコントローラ108は、様々なDRAMハードウェア保守イベントをスケジュール、制御、および実行するための様々なモジュール130を含む。下記でより詳細に説明するように、DRAMコントローラ108は、CPU106、およびオペレーティングシステム120によって提供される機能(たとえば、カーネルスケジューラ122、割込みハンドラ124など)とのシグナリングおよび通信により、DRAMハードウェア保守の様々な態様を実施してもよい。この点について、メモリハードウェア保守モジュール130は、たとえば、割込み要求(IRQ)バス117を介してCPU106への割込み信号を生成し、送信することによって、DRAM保守イベントのスケジューリングを開始するために、スケジューラモジュール132をさらに含んでもよい。スケジューラモジュール132は、スケジュールされた保守イベントを実行するためにタイムオブサービス(ToS)ウィンドウを定義するためにタイマ/制御モジュール134を組み込んでもよい。一実施形態では、DRAMハードウェア保守イベントは、当技術分野で知られているように、リフレッシュ動作と、較正動作と、トレーニング動作とを含んでもよい。リフレッシュモジュール136が、DRAM104の揮発性メモリをリフレッシュするための論理を含む。較正モジュール138が、電圧信号レベルを定期的に較正するための論理を含む。トレーニングモジュール140が、DRAM動作の間に使用されるタイミングパラメータを定期的に調整するための論理を含む。
図2は、DRAMハードウェア保守イベントをスケジュール、制御、および実行する際に使用される様々な構成要素間の対話の一実施形態を示す。(DRAMコントローラ108にある)スケジューラ132およびタイマ/制御モジュール134は、オペレーティングシステム120の割込みハンドラ124とインターフェースする。CPU106は、DRAMコントローラ108から、DRAMハードウェア保守イベントがカーネルスケジューラ122によってスケジュールされることを示す割込み信号を受信する。割込みを受信すると、CPU106上で動作している割込みハンドラ124は、受信した割込み信号に関連する特定のDRAMハードウェア保守イベントの優先順位を割り当てるために使用されてもよい優先順位表202とインターフェースする。割込みハンドラ124は、優先順位表202によって規定された優先順位に従ってDRAMハードウェア保守イベントをスケジュールするために、カーネルスケジューラ122とインターフェースする。異なるタイプの保守イベントのすべてにサービスするために、対応する割込みハンドラを用いた複数の割込みが使用される場合があることを諒解されたい。
図3は、DRAMハードウェア保守イベントのカーネルスケジューリングを提供するためのシステム100によって実施される方法300を示す。ブロック302において、DRAMコントローラ108は、カーネルスケジューラ122を介して1つまたは複数のDRAMハードウェア保守イベントをスケジュール、制御、および実行するためにタイムオブサービス(ToS)ウィンドウを決定する。図4は、例示的なToSウィンドウ408を示すメモリ保守イベントタイムライン400を示す。タイムライン400のy軸は、時間(x軸)によるメモリ保守イベントを表す。一実施形態では、ToSウィンドウ408は、DRAMハードウェア保守イベントが実行されてもよい、割込み信号402と所定のデッドラインとの間の継続時間として規定される。図4に示すように、割込み信号402は、基準線404によって示される時間t1に受信される場合がある。DRAMコントローラ108は、スケジュールされたDRAM保守イベントが、基準線406によって示されるデッドライン時間t2までに完了されたかどうかを決定するために、タイマおよび制御モジュール134によりToSウィンドウ408を監視してもよい。
再び図3を参照すると、ブロック304において、DRAMコントローラ108は、1つまたは複数のDRAMハードウェア保守イベントがToSウィンドウ408の間に実行されることを示す1つまたは複数の割込み信号402をCPU106に提供する。割込みハンドラ124は、割込み信号402を受信する。ブロック306において、割込み信号402に応答して、割込みハンドラ124は、ToSウィンドウ408の間にスケジュールされる1つまたは複数のDRAMハードウェア保守イベントの優先順位を決定してもよい。ToSウィンドウ408は、CPU106の負荷が少なく、重要な、高い優先順位のタスクを完了できるようにする、CPUアイドル時間の間に実行されるように、またはそのいずれも優先順位表202に具体化される場合がある他の優先順位方式に従って、1つまたは複数のDRAM保守イベントが、最適に延期される場合がある利用可能なサービスウィンドウを表すことを諒解されたい。DRAM保守イベントが、既存のシステムによって要求される独立した保守イベントとしてではなく保守イベントのバッチとして、たとえば、複数のリフレッシュコマンドを発行することによって、またはリフレッシュイベントとトレーニングイベントを組み合わせることによって、ToSウィンドウ408の間に実行されるようにスケジュールされてもよいことをさらに諒解されたい。このようにして、メモリアクセス衝突が解消される、または著しく減少する場合があり、CPUプロセスメモリ効率が向上する場合がある。
一実施形態では、優先順位は、たとえば、保守イベントのタイプ(たとえば、リフレッシュ、較正、トレーニングなど)、負荷センサ126によって決定される現在のCPU負荷、センサ128によって決定される現在のDRAM温度のうちの1つまたは複数に基づく優先順位表202に従って決定されてもよい。ブロック308において、1つまたは複数のDRAMハードウェア保守イベントは、割込みハンドラ124によって、ブロック306の間に決定された優先順位に従ってカーネルスケジューラ122の入力キューに新しいスレッドとして挿入される。カーネルスケジューラ122は、優先順位に基づいてそのキューにアクティビティのすべてを公平にディスパッチするために標準的な実行に従ってもよい。ブロック310において、1つまたは複数のDRAMハードウェア保守イベントは、優先順位に従ってカーネルスケジューラ122を介して実行されてもよい。上述のように、一実施形態では、DRAMハードウェア保守イベントは、ToSウィンドウ408内の有利な時間に単一のより長いDRAM保守動作を形成するために、合わせてグループ化されてもよい。スケジュールされたDRAMハードウェア保守イベントが実行される前にToSウィンドウ408が終了する(すなわち、デッドラインt2に達する)場合は、タイマおよび制御モジュール134は、カーネルスケジューリングを無効にし、CPU106上のトラフィックをストールすること、および所望の保守を実行することによってハードウェア介入を実行してもよい。介入が行われる場合、タイマおよび制御モジュール134は、CPU106によってアクセスされる場合がある過去の介入のログを保持してもよい。
図5は、3つの処理スレッド(スレッドA502、スレッドB504、およびスレッドC506)に関するDRAMリフレッシュ動作のスケジューリングを含むシステム100の別の例示的な実装形態を示す。図5に示すように、オペレーティングシステム120は、メモリ動作およびDRAMハードウェア保守イベントをスケジュールするための1つまたは複数の優先順位に基づく入力キューを含んでもよい。この例では、システムは、3つの優先順位レベルをサポートする。入力キュー508が、最も高い優先順位(優先順位0)に関連する動作をスケジュールするために使用される。入力キュー510が、次に最も高い優先順位(優先順位1)に関連する動作をスケジュールするために使用される。入力キュー512が、最も低い優先順位(優先順位2)に関連する動作をスケジュールするために使用される。任意の数の優先順位レベル、タイプ、および方式がサポートされてもよいことを諒解されたい。
上記で説明したように、DRAM104が、リフレッシュモジュール136、較正モジュール138、およびトレーニングモジュール140からの定期的なハードウェアサービスイベントを含んでもよい。一実施形態では、モジュール136、138、および140は、モジュール134によって提供されるタイマを使用して定期的なサービスインターバルを追跡するためのそれぞれのハードウェアを含んでもよい。各タイマは、対応するDRAMハードウェア保守イベントがその中で完了されるべきToSウィンドウ408を追跡してもよい。
各イベント手法のタイムオブサービスとして、スケジューラ132が、CPU106への割込み信号402を発行してもよい。割込み信号402が、オペレーティングシステム120の割込みハンドラ124に、優先順位表202に基づいて入力キュー508、510、および512のうちの1つに対応するイベントスレッドを追加させてもよいことを諒解されたい。図8は、割込みハンドラ124がリフレッシュ動作のための割込み信号402を受信する例を示す。割込みハンドラ124は、優先順位表202にアクセスし、リフレッシュ動作は、最も低い優先順位(すなわち、優先順位2動作のための入力キュー512)に割り当てられることを決定してもよい。優先順位は、負荷センサ126および/または温度センサ128からの入力に基づいて決定されてもよい。図8の例では、スレッドA502が、優先順位0動作として入力キュー508に追加され、スレッドB504が、優先順位1動作として入力キュー510に追加され、スレッドC506が、優先順位2動作として入力キュー512に追加される。割込みハンドラ124が、リフレッシュ動作は優先順位2動作を割り当てられると決定した後、リフレッシュスレッド802が、優先順位2動作に対応する入力キュー512に追加されてもよい。
カーネルスケジューリングアルゴリズムに従って、カーネルスケジューラ122は、スレッドA、B、およびC、ならびにリフレッシュスレッド802をディスパッチしてもよい。一実施形態では、カーネルスケジューリングアルゴリズムは、たとえば、当技術分野でよく知られている、静的優先順位方式、優先順位付けされたラウンドロビン方式、または優先順位付けされたピンポン方式に従ってもよい。リフレッシュスレッド802が実行されるとき、対応するリフレッシュドライバ514が、DRAMコントローラ108内のリフレッシュモジュール136にリフレッシュイベントを実行するよう命令するために使用されてもよいことを諒解されたい。さらなる較正およびトレーニングドライバ514が、較正モジュール138およびトレーニングモジュール140にそれぞれ対応するDRAM保守イベントを実行するように命令するために使用されてもよい。サービスする前に、各ドライバ514が、イベントが実行されるより前にToSウィンドウ408が終了することにより、ハードウェア介入がすでに行われているかどうかを決定するために、ハードウェアをチェックしてもよいことを諒解されたい。
上述のように、モジュール134内のタイマは、サービスイベントが完了されるべきデッドラインを追跡してもよい。たとえば、重いCPU負荷の下では、DRAM保守イベントスレッドおよび関連するドライバ514が、デッドラインの前に実行されない場合がある。これが発生する場合、DRAMコントローラ108は、タイマによって追跡されるデッドラインを認識し、ハードウェアが直ちに介入し、CPUトラフィックをストールし、必要とされるDRAMサービスを実行する。介入の後、ハードウェアは、前述のように続行されてもよい。
図6は、DRAMコントローラ108がカーネルスケジューラ122を介してスケジュールすることなく、図5の例においてDRAM104を定期的にリフレッシュするための従来の方法の一実施形態を示すメモリトラフィックタイムラインである。この例は、カーネルスケジューリング、優先順位などを顧慮せずに、独立したサービスイベントとして、リフレッシュ動作を定期的にスケジュールするための従来の手法を示すことを諒解されたい。図6に示すように、個々のリフレッシュ602が、カーネルスケジューラ122を介してDRAMコントローラ108によってスケジュールされるのではなく、一定の周期で行われる。したがって、スレッドA502、スレッドB504、およびスレッドC506を処理するとき、各リフレッシュ602は、リフレッシュ動作が実行されることを可能にするために、対応するスレッドがストールされることを必要とする。図7は、上記で説明したシステムおよび方法がリフレッシュ602のグループをスケジュールするために使用される図6の例を示す。図7は、アイドル時間の間に実行されるようにリフレッシュ602をスケジュールし、それによってCPUプロセスメモリ効率を向上させることによって、各メモリアクセス衝突が回避される場合があることを示す。
図9は、優先順位表202を生成するための優先順位較正方法900の一実施形態を示すフローチャートである。方法900に使用されるいくつかの値は、異なるプラットフォーム、メモリタイプ、ソフトウェアビルドなどに対応するように調整される場合があることは、当業者には認識されよう。値は、相手先商標製造会社(OEM)によって提供される場合があることをさらに諒解されたい。
ブロック902に示すように、優先順位較正は、様々な温度値にわたって実行されてもよい。ブロック904において、優先順位較正は、CPU負荷の様々な値(たとえば、パーセンテージ値、範囲など)にわたって実行されてもよい。値にわたるスイープの間、較正、トレーニング、およびリフレッシュハードウェアイベントのスレッド優先順位は、下げられてもよい。これは、整数値優先順位を0から、(スケジューリングがToSウィンドウ内で完了しないときの)ハードウェア介入の数がしきい値を超えるまで増やすことに対応することを諒解されたい。その時点において、優先順位は、その温度値(T)およびCPU負荷値(X)に対してログ記録されてもよく(ブロック912)、その後フローは、ブロック904に戻されてもよい。図9を参照すると、ブロック906は、システムがハードウェア介入をカウントするためにある固定時間期間の間実行されてもよいことを示す(ブロック908)。決定ブロック910では、ハードウェア介入の数がしきい値未満である場合、優先順位は、下げられてもよい。ハードウェア介入の数がしきい値を超える場合、ブロック912が実行される。
図10は、温度値(列1004)およびCPUパーセンテージ負荷(行1002)の組合せに対する優先順位値を含む例示的な優先順位表202を示す。たとえば、温度値85度およびCPU負荷80%に対する優先順位値は、CPU負荷が重くおよびDRAM温度が高いために最も高い優先順位レベル(優先順位=0)を割り当てられてもよい。
上述のように、DRAMコントローラ108は、スケジュールされたDRAM保守イベントが、対応するデッドラインまでに完了されたかどうかを決定するために、タイマおよび制御モジュール134によりToSウィンドウ408を監視してもよい。図11は、リフレッシュ602のグループがスレッド1101および1103の実行間のアイドル時間のToSウィンドウ1106の間に、正常にスケジュールされ、実行されることを示すタイムライン1100である。図12は、スレッド1101が実行されている間に、またリフレッシュ602のグループが実行される前に、ToSウィンドウ1106が終了するタイムライン1200を示す。この状況では、DRAMコントローラ108は、デッドラインを逸したことを検出し、上記で説明したようにハードウェア介入を開始する。各タイプの保守イベントに対する介入の実行履歴が、カウンタによってログ記録されてもよく、カウンタは、CPU106上で実行しているオペレーティングシステム120によって読み取られる、および/またはリスタートされることが可能である。オペレーティングシステム120は定期的に、この介入履歴を読み取り、クリアし、以前の読取りのログを不揮発性メモリ118に記憶してもよい。これは、オペレーティングシステム120が、たとえば、図9のブロック908と等しい継続時間の、固定連続時間期間にわたって行われた介入の数を測定することを可能にする。不揮発性メモリ118に記憶されたログは、システム100が許容できる較正にとどまっていること、および介入の発生が著しく悪化していないことを保証するために、オペレーティングシステム120によって使用されてもよい。たとえば、ログが、システム100が劣化し、図9のブロック910に記載する較正しきい値の値を超える介入に遭遇したことを示す場合、システムは、すべてのテーブルエントリ(すでに最高である優先順位0を含まない)の優先順位を直ちに上げて、それにより介入率を下げることによって、優先順位表202を意図的に調節してもよい。反対に、ログが、延長時間期間(たとえば、図9のブロック908の例示的な実施形態で使用される時間期間よりも例外的に長い、48時間)の間に、システム100がゼロまたはゼロに近い介入を経験することを報告する場合、これは、優先順位表202エントリが、必要以上に高く優先順位付けられたことを示す可能性があり、システム100は、各エントリの優先順位を下げ、したがって介入率が上がるようにするための機能を含んでもよい。
上述のように、システム100は、任意の望ましいコンピューティングシステムに組み込まれてもよい。図13は、SoC102を含む例示的なポータブルコンピューティングデバイス(PCD)1300を示す。この実施形態では、SoC102は、マルチコアCPU1302を含む。マルチコアCPU1302は、第0のコア1310、第1のコア1312、および第Nのコア1314を含んでもよい。コアのうちの1つは、たとえば、グラフィックス処理ユニット(GPU)を含み、他のコアのうちの1つまたは複数はCPUを含む場合がある。
ディスプレイコントローラ328およびタッチスクリーンコントローラ330は、CPU1302に結合されてもよい。一方、SoC102の外部にあるタッチスクリーンディスプレイ1306は、ディスプレイコントローラ328およびタッチスクリーンコントローラ330に結合されてもよい。
図13は、ビデオエンコーダ334、たとえば、位相反転線(PAL)エンコーダ、順次式カラーメモリ(SECAM)エンコーダ、または全米テレビジョン方式委員会(NTSC)エンコーダが、マルチコアCPU1302に結合されることをさらに示す。さらに、ビデオ増幅器336がビデオエンコーダ334とタッチスクリーンディスプレイ1306とに結合される。また、ビデオポート338がビデオ増幅器336に結合される。図13に示すように、ユニバーサルシリアルバス(USB)コントローラ340が、マルチコアCPU1302に結合される。同様に、USBポート342が、USBコントローラ340に結合される。DRAM104および加入者識別モジュール(SIM)カード346はまた、マルチコアCPU1302に結合されてもよい。
さらに、図13に示すように、デジタルカメラ348は、マルチコアCPU1302に結合される場合がある。例示的な態様において、デジタルカメラ348は、電荷結合デバイス(CCD)カメラまたは相補型金属酸化物半導体(CMOS)カメラである。
図13にさらに示すように、ステレオオーディオコーダ-デコーダ(コーデック)350が、マルチコアCPU1302に結合されてもよい。さらに、オーディオ増幅器352が、ステレオオーディオコーデック350に結合されてもよい。例示的な態様では、第1のステレオスピーカー354および第2のステレオスピーカー356が、オーディオ増幅器352に結合される。図13は、マイクロフォン増幅器358もステレオオーディオコーデック350に結合される場合があることを示している。さらに、マイクロフォン360が、マイクロフォン増幅器358に結合されてもよい。特定の態様では、周波数変調(FM)無線チューナ362が、ステレオオーディオコーデック350に結合されてもよい。また、FMアンテナ364が、FM無線チューナ362に結合される。さらに、ステレオヘッドフォン366は、ステレオオーディオコーデック350に結合されてもよい。
図13は、無線周波数(RF)トランシーバ368がマルチコアCPU1302に結合される場合があることをさらに示す。RFスイッチ370が、RFトランシーバ368とRFアンテナ372とに結合される場合がある。キーパッド204が、マルチコアCPU1302に結合される場合がある。また、マイクロフォンを備えたモノヘッドセット376が、マルチコアCPU1302に結合される場合がある。さらに、バイブレータデバイス378がマルチコアCPU1302に結合される場合がある。
図13はまた、電源380がSoC102およびSoC202に結合される場合があることを示す。特定の態様では、電源380は、電力を必要とするPCD1300の種々の構成要素に電力を供給する直流(DC)電源である。さらに、特定の態様では、電源は、充電式DCバッテリー、または交流(AC)電源に接続されたAC/DC変換器から得られるDC電源である。
図13はさらに、PCD1300がまた、データネットワーク、たとえば、ローカルエリアネットワーク、パーソナルエリアネットワーク、または任意の他のネットワークにアクセスするために使用される場合があるネットワークカード388を含んでもよいことを示す。ネットワークカード388は、Bluetooh(登録商標)ネットワークカード、WiFiネットワークカード、パーソナルエリアネットワーク(PAN)カード、パーソナルエリアネットワーク超低電力技術(PeANUT)ネットワークカード、テレビジョン/ケーブル/衛星チューナ、または当技術分野でよく知られている任意の他のネットワークカードである場合がある。さらに、ネットワークカード388は、チップに組み込まれる場合があり、すなわち、ネットワークカード388は、チップ内のフルソリューションである場合があり、別個のネットワークカード388でなくてもよい。
図13を参照すると、メモリ104、タッチスクリーンディスプレイ1306、ビデオポート338、USBポート342、カメラ348、第1のステレオスピーカー354、第2のステレオスピーカー356、マイクロフォン360、FMアンテナ364、ステレオヘッドフォン366、RFスイッチ370、RFアンテナ372、キーパッド204、モノヘッドセット376、バイブレータ378、および電源380は、オンチップシステム102の外部に存在する場合があることを諒解されたい。
揮発性メモリ保守イベントをスケジュールするための上記で説明したシステムおよび方法は、同じ揮発性メモリを共有する2つ以上の独立したメモリクライアントを含むマルチプロセッサSoCに組み込まれる場合があることを諒解されたい。図14は、図1のSoC102が3つのメモリクライアント、すなわち、CPU106、グラフィック処理ユニット(GPU)1402、およびモデム処理ユニット(MPU)1404を含む一実施形態を示す。各プロセッサは、自律的に、互いから独立して動作するが、SoCバス116を介して、互いと、ならびにROM112、SRAM110、DRAMコントローラ108、およびストレージコントローラ114に通信することができる。上記で説明し、図14に示すように、CPU106、GPU1402、およびMPU1404は、マルチクライアント決定モジュール1400によって含められ、IRQバス117を介してDRAMコントローラ108から割込み信号を受信するように登録してもよい。
任意の数のさらなるプロセッサおよび/またはプロセッサタイプが、SoC102に組み込まれてもよい。各プロセッサタイプは、それらのそれぞれのプロセッサタイプで動作しているカーネルおよびスケジューリング関数(たとえば、図1のカーネルスケジューラ122、割込みハンドラ124)のコマンドの下でスレッドを実行する、単数および/または複数の並列実行ユニットを含んでもよい。図14にさらに示すように、CPU106、GPU1402、およびMPU1404は、それぞれオペレーティングシステム120a、120b、および120cを、対応する負荷センサ126a、126b、および126cとともに備えてもよい。図1〜図13に関して上述したカーネルスケジューリングシステムおよび方法は、CPU106、GPU1402、およびMPU1404の各々に対して拡大されてもよい。
下記でより詳細に説明するように、DRAMコントローラ108は、SoCプロセッサの各々のカーネルスケジューリングを考慮に入れることによってDRAM保守イベントをいつスケジュールするかを決定するための論理を含むマルチクライアント決定モジュール1400をさらに含んでもよい。カーネルスケジューリングは、上記で説明した方法で実行されてもよい。ToS手法としての、図14のマルチプロセッサ環境では、タイマおよび制御モジュール134は、CPU106、GPU1402、およびMPU1404の各々に、1つまたは複数の割込みを発行してもよい。応答して、各オペレーティングシステム120a、120b、および120c内の割込みサービスルーチン(ISR)は、それらのそれぞれのスケジューラ入力キュー上に対応するイベントを発行してもよい。この点について、イベントは、各プロセッサタイプに対して、複製され、キューイングされてもよい。アクティブでないまたはスリープ状態であるプロセッサは、割込みに応答することから一時的に除外され、それらが再びアクティブになるまでマルチクライアント決定モジュール1400の処理から除外されてもよい。任意のプロセッサが、それ自体を任意の時間にマルチクライアント決定から除外してもよい。各プロセッサが、たとえば、プロセッサの割込みハンドラ124から保守イベント割込み117をマスクすることに加えて、このプロセッサはもはやマルチクライアント決定に含められるべきではないことを意味する、マルチクライアント決定モジュール1400への書込みを実行することによって、これを行ってもよい。
CPU106、GPU1402、およびMPU1404は、独立して動作し、DRAMコントローラ108への別個のスケジュール通知を生成し、提供することによってDRAM保守イベントをスケジュールする。一実施形態では、各プロセッサカーネルスケジューラが、それら自体の「保守に最良の時間」を決定し、次いで、各プロセッサからの受信したスケジュール通知に基づいて実際のスケジューリングを決定する最終的な権限を有するDRAMコントローラ108を用いて、通知を独立してスケジュールする。DRAMコントローラ108は、スケジュール通知を、任意の一貫性のあるパターンに従うのではなく順不同に受信してもよいことを諒解されタイマルチクライアント決定モジュール1400は、DRAM保守イベントをいつ実行するかを決定するために、記憶された特性付けデータならびにDRAMトラフィック利用データを活用してもよい。メモリトラフィック利用モジュール1406(図14)が、DRAM104上のトラフィックアクティビティの現在のレベルを決定し、報告してもよい。このようにして、各SoCプロセッサに対するカーネルスケジューラは、DRAM保守イベントを実行するのに最適な時間を個別に決定してもよいが、マルチクライアント決定モジュール1400は、それをいつ行うかの最終的な決定を行う。
図15は、マルチクライアント決定モジュール1400の一実施形態の一般的な動作およびデータ入力を示す。CPU106、GPU1402、およびMPU1404が独立して、通知1502を提供することによって、マルチクライアント決定モジュール1400に、DRAM保守イベントを実行するのに最適な時間を通知する。通知1502は、DRAMコントローラ108への書込み動作によって実施されてもよい。
図19は、クライアントID 1902、クライアント優先順位データ1904、クライアント負荷データ1906、および保守イベントID 1908を含む書込み動作1900の例示的な実装形態を示す。クライアントID 1902は、どのプロセッサが通知1502を送信しているかを識別するために使用されてもよい。クライアント優先順位データ1904は、プロセッサに割り当てられた優先順位を含んでもよい。一実施形態では、各プロセッサタイプ(たとえば、CPU、GPU、MPUなど)が、あらかじめ定義された優先順位方式に従って優先順位を割り当てられてもよい。プロセッサの優先順位は、DRAMアクセス待ち時間に対する感度(sensitivity)と逆である。言い換えれば、待ち時間に比較的より影響されやすい(sensitive)プロセッサは、より高い優先順位を割り当てられてもよい。図14の例では、MPU1404は、「最も高い優先順位」を、GPU1402は「最も低い優先順位」を、CPUは「中間の優先順位」を割り当てられてもよい。図15に示すように、優先順位データは、通知を用いて与えられなくてもよい。代替実施形態では、プロセッサ優先順位データ1502は、DRAMコントローラ108に記憶される、または場合によっては与えられてもよい。再び図19を参照すると、書込み動作1900によって与えられるクライアント負荷データ1906は、たとえば、プロセッサによってわかる平均負荷(すなわち、プロセッサ利用率)を含んでもよい。プロセッサ利用率は、負荷センサ126によって測定されてもよい。保守イベントID 1908は、スケジュールされているDRAM保守イベントのタイプを識別するイベントタイプ(たとえば、リフレッシュ、トレーニング、較正)を含んでもよい。一実施形態では、保守イベントID 1908はまた、プロセッサからマルチクライアント決定モジュール1400に設定およびステータス情報を送信するために使用されてもよい。たとえば、独立したクライアント負荷データ1906が、各プロセッサによって定期的に送信されてもよく、またはマルチクライアント決定から一時的に取り除かれるように、プロセッサから除外要求が送信されてもよい。
再び図15を参照すると、マルチクライアント決定モジュール1400は、1つまたは複数の決定ルールに従ってDRAM保守イベントをいつ実行するかを決定するように構成されてもよい。一実施形態では、決定ルールは、通知による通知ベースで適用される。言い換えれば、各通知1502が受信されるとき、決定ルールはその通知に適用される。マルチクライアント決定モジュール1400は、様々なタイプのデータを使用して決定ルールを適用してもよい。図15の実施形態では、入力データは、決定表1506、プロセッサ優先順位データ1504、およびメモリトラフィック利用データ1508を含む。例示的な決定表1506について、図18を参照して下記で説明する。メモリトラフィック利用データ1508は、モジュール1406(図14)によって提供されてもよい。
図16は、図14のマルチプロセッサSoC内でDRAM保守イベントをスケジュールするためのルールベースの方法1600の一実施形態を示すフローチャートである。ブロック1602において、DRAMコントローラ108は、DRAM保守イベントを実行するためにToSウィンドウを決定してもよい。ブロック1604において、DRAMコントローラ108は、SoC102上の複数のプロセッサの各々に割込み信号を提供する。ブロック1606において、各プロセッサが独立して、対応する通知1502を生成することによって、DRAM保守イベントをスケジュールする。ブロック1602、1604、および1606は、上記で説明したように動作してもよい。
各通知1502がDRAMコントローラ108によって受信されるとき(ブロック1608)、マルチクライアント決定モジュール1400は、DRAM保守イベントをいつ実行するかを決定するために、1つまたは複数の決定ルールを適用してもよい。マルチクライアント決定モジュール1400は、現在のToSウィンドウの間にどのプロセッサが通知を送信したかを追跡してもよい。決定ブロック1610において、マルチクライアント決定モジュール1400は、現在の通知の優先順位よりも高い優先順位を有する未処理の通知1502があるかどうかを決定してもよい。現在の通知よりも高い優先順位を有する未処理の通知がある場合、マルチクライアント決定モジュール1400は、次の通知1502の到着を待ってもよい(ブロック1608まで制御を戻す)。たとえば、現在の通知1502が、「最も低い優先順位」を有するGPU1402から受信されたと考える。通知がCPU106またはMPU1404(これらの両方がより高い優先順位を有する)からまだ受信されていない場合、DRAMコントローラ108は、次の通知を受信するのを待ってもよい。現在の通知よりも高い優先順位を有する未処理の通知がない場合、制御は、決定ブロック1612に移る。決定ブロック1612において、マルチクライアント決定モジュール1400は、「直ちに作動(go now)」し、DRAM保守イベントにサービスするか、1つまたは複数のプロセッサからさらなる通知を受信するのを待つかを決定する。最も高い優先順位のプロセッサが、最後に通知に応答する場合、これは、未処理の通知がないことを意味し、ルールベースの方法1600は、自動的にブロック1614に進んでもよい。
一実施形態では、決定ブロック1612は、決定表1506(図15)にアクセスすることによって実施されてもよい。図18は、CPU負荷(列1802)、GPU負荷(列1804)、およびMPU負荷(列1806)の様々な組合せに基づいて、"go now"または"wait"アクション(列1808)を指定する、例示的な決定表1506を示す。図18の例では、プロセッサ負荷は、"low"または"high"値によって指定されるが、数値範囲または他の値が実装されてもよい。書込み動作1900による次の値更新が、現在の値を上書きするまで、プロセッサ負荷値1802、1804、および1806は、保持されてもよい。DRAM保守イベントがない間でもマルチクライアント決定モジュール1400に正確な負荷情報を提供するために、プロセッサ負荷値更新が、定期的に送信されてもよい。
再び図16を参照すると、決定表1506が"wait"アクションを示す場合、制御はブロック1608に戻る。決定表1506が"go now"アクションを示す場合、DRAMコントローラ108は、DRAMトラフィック利用を監視することを始めてもよい(ブロック1614)。DRAMトラフィック利用が、所定の、またはプログラム可能なしきい値を下回るとき(決定ブロック1620)、DRAMコントローラ108は、DRAMイベントにサービスすることを始めてもよい(ブロック1622)。DRAMトラフィック利用を監視しながら、DRAMコントローラ108は、ToSウィンドウが終了したかどうかを追跡してもよい(決定ブロック1616)。DRAM保守イベントにサービスする前にToSウィンドウが終了する場合、DRAMコントローラは、上記で説明したようにハードウェア介入を実行してもよい(ブロック1618)。
図17は、ルールベースの方法1600の動作の2つの例を示すタイムラインである。タイムライン1700は、DRAMコントローラ108によって受信された通知1502の順番を示し、タイムライン1702は、DRAM保守イベントにサービスするための、結果として生じるタイミングを示す。タイムライン1700を参照すると、第1の通知1704aが、CPU106(「中間の優先順位」)から受信される。より高い優先順位プロセッサ(すなわち、GPU1402およびMPU1404)から通知はまだ受信されていないので、DRAMコントローラ108は、次の通知を待つ。第2の通知1706aが、GPU1402(「最も低い優先順位」)から受信される。最も高い優先順位プロセッサ(MPU1404)が未処理のままであるので、DRAMコントローラは、トラフィック利用モジュール1406をチェックし、ToSウィンドウ1711a内でDRAM保守イベントにサービスする前に、最後の通知(1708a)を受信するのを待つ。タイムライン1702は、最後の通知1708aが受信されるとき、信号1710aが生成されることを示す。
その後の時間に、第2のDRAM保守イベントがスケジュールされてもよい。このDRAM保守イベントの場合、通知は、異なる順番で受信される。第1の通知1708aは、「最も高い優先順位」を有するMPUから受信される。通知1708aを受信することに応答して、DRAMコントローラ108は、より高い優先順位を有する未処理の通知はないと決定してもよい。それに応じて、マルチクライアント決定モジュール1400は、DRAMにサービスすることを始める("go now"アクション)か、それとも次の通知まで待つ("wait"アクション)かを決定するために、決定表1506にアクセスしてもよい。この例では、MPU1404は、"high"負荷を有し(図18の2行目)、マルチクライアント決定モジュール1400は、対応するアクションは"wait"であると決定する。決定表1506に基づいて、DRAMコントローラ108は、CPU106(「中間の優先順位」)から次の通知1704bを受信するのを待つ。GPU1402に関連する未処理の通知は、より高い優先順位ではないので、マルチクライアント決定モジュール1400は、DRAMにサービスすることを始める(たとえば、"go now"アクション)か、それとも次の通知まで待つ(たとえば、"wait"アクション)かを決定するために、決定表1506にアクセスしてもよい。この例では、CPU106の書込み動作1900は、"high"負荷を示す。さらに、MPU1404は、その負荷を"high"から"low"値に更新した別個の書込み動作1900を行っており、マルチクライアント決定モジュール1400は、対応するアクション(たとえば、図18の3行目)は"go now"であると決定する。トラフィック利用モジュール1406は、図16のブロック1620で説明するように、しきい値を下回るメモリトラフィックをチェックされてもよく、次いでDRAMコントローラは、DRAM保守イベントにサービスすることを始める。タイムライン1702は、通知1704bが受信されるとき、また最も低い優先順位のプロセッサ(すなわち、GPU1402)から通知1706bを受信する前に、信号1710bが生成されることを示す。現在のToSウィンドウ1711bの間にDRAM保守はすでに完了しているので、GPU1402の通知1706bは、依然として行われる場合があるが、マルチクライアント決定モジュール1400によって無視されてもよい。たとえば、図17に示すように、信号1710bが発せられるとき、ToSウィンドウ1711bは閉じられてもよい。
本明細書で説明した方法ステップのうちの1つまたは複数は、上記のモジュールなどのコンピュータプログラム命令としてメモリに記憶される場合があることを諒解されたい。これらの命令は、本明細書で説明した方法を実行するために、対応するモジュールと組み合わせてまたは協働して、任意の適切なプロセッサによって実行される場合がある。
本発明が説明したように機能するために、本明細書で説明したプロセスまたはプロセスフローにおけるいくつかのステップが、他のステップに先行するのは当然である。しかしながら、そのような順序またはシーケンスが本発明の機能を変えない場合、本発明は、説明したステップの順序に限定されない。すなわち、本発明の範囲および趣旨から逸脱することなく、いくつかのステップは、他のステップの前に実行されるか、後に実行されるか、または他のステップと並行して(実質的に同時に)実行されてもよいことを認識されたい。場合によっては、本発明から逸脱することなく、いくつかのステップが省略されてもよく、または実行されなくてもよい。さらに、「その後」、「次いで」、「次に」などの語は、ステップの順番を限定することを意図していない。これらの言葉は単に、例示的な方法の説明に読者を導くために使用される。
さらに、プログラミングに関する当業者は、たとえば、本明細書におけるフローチャートおよび関連する説明に基づいて、難なく、開示した発明を実装するコンピュータコードを書くことができるか、または実装するのに適したハードウェアおよび/もしくは回路を識別することができる。
したがって、特定の1つのセットのプログラムコード命令または詳細なハードウェアデバイスの開示は、本発明の作製方法および使用方法を十分に理解するのに必要であるとは見なされない。特許請求されるコンピュータ実施プロセスの発明性のある機能は、上記の説明において、かつ様々なプロセスフローを示す場合がある図面とともに、より詳細に説明される。
1つまたは複数の例示的な態様では、説明する機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装されてもよい。ソフトウェアで実装される場合、機能は、1つもしくは複数の命令またはコードとして、コンピュータ可読媒体上に記憶される場合もあり、またはコンピュータ可読媒体上で送信される場合もある。コンピュータ可読媒体は、コンピュータ記憶媒体と、コンピュータプログラムのある場所から別の場所への転送を容易にする任意の媒体を含む通信媒体の両方を含む。記憶媒体は、コンピュータによってアクセスされる場合がある任意の利用可能な媒体であってもよい。限定ではなく例として、そのようなコンピュータ可読媒体は、RAM、ROM、EEPROM、NANDフラッシュ、NORフラッシュ、M-RAM、P-RAM、R-RAM、CD-ROMもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気記憶デバイス、または命令もしくはデータ構造の形態で所望のプログラムコードを搬送もしくは記憶するために使用され、コンピュータによってアクセスされてもよい任意の他の媒体を備えてもよい。
また、いかなる接続も、厳密にはコンピュータ可読媒体と呼ばれる。たとえば、ソフトウェアが、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線(「DSL」)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用してウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。
ディスク(disk)およびディスク(disc)は、本明細書で使用するとき、コンパクトディスク(disc)("CD")、レーザーディスク(登録商標)(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)("DVD")、フロッピーディスク(disk)、およびブルーレイディスク(disc)を含み、ディスク(disk)は、通常、データを磁気的に再生する一方で、ディスク(disc)は、データをレーザーで光学的に再生する。上記の組合せも、コンピュータ可読媒体の範囲に含まれるべきである。
本発明の趣旨および範囲から逸脱することなく、本発明が関係する代替的な実施形態が、当業者には明らかになるであろう。したがって、選択された態様が図示され詳細に説明されてきたが、以下の特許請求の範囲によって定義されるように、本発明の趣旨および範囲から逸脱することなく、各態様において様々な置換および改変が行われてよいことが理解されよう。
100 システム
102 システムオンチップ(SoC)
104 ダイナミックランダムアクセスメモリ(DRAM)
105 制御バス
106 中央処理装置(CPU)
107 データバス
108 DRAMコントローラ
110 スタティックランダムアクセスメモリ(SRAM)
112 読取り専用メモリ(ROM)
114 ストレージコントローラ
116 SoCバス
117 割込み要求(IRQ)バス
118 不揮発性メモリ
120 オペレーティングシステム(OS)
122 カーネルスケジューラ
124 割込みハンドラ
126 負荷センサ
128 温度センサ
130 メモリハードウェア保守モジュール
132 スケジューラモジュール
134 タイマおよび制御モジュール
136 リフレッシュ
138 較正
140 トレーニング
202 優先順位表
204 キーパッド
328 ディスプレイコントローラ
330 タッチスクリーンコントローラ
334 ビデオエンコーダ
336 ビデオ増幅器
338 ビデオポート
340 ユニバーサルシリアルバス(USB)コントローラ
342 USBポート
346 加入者識別モジュール(SIM)カード
348 デジタルカメラ
350 ステレオオーディオコーダ-デコーダ
352 オーディオ増幅器
354 第1のステレオスピーカー
356 第2のステレオスピーカー
358 マイクロフォン増幅器
360 マイクロフォン
362 周波数変調(FM)無線チューナ
364 FMアンテナ
366 ステレオヘッドフォン
368 無線周波数(RF)トランシーバ
370 RFスイッチ
372 RFアンテナ
376 モノヘッドセット
378 バイブレータ
380 電源
388 ネットワークカード
602 CPU
802 マルチコアCPU
1300 ポータブルコンピューティングデバイス(PCD)
1302 マルチコアCPU
1306 タッチスクリーンディスプレイ
1310 第0のコア
1312 第1のコア
1314 第Nのコア
1400 マルチクライアント決定モジュール
1402 グラフィック処理ユニット(GPU)
1404 モデム処理ユニット(MPU)
1406 モジュール
1900 書込み動作
1902 クライアントID
1904 クライアント優先順位
1906 クライアント負荷データ
1908 保守イベントID

Claims (30)

  1. 揮発性メモリ保守イベントをスケジュールするための方法であって、
    メモリデータインターフェースを介してメモリコントローラに結合される揮発性メモリデバイスに対して保守イベントを実行するために前記メモリコントローラがタイムオブサービス(ToS)ウィンドウを決定するステップと、
    前記保守イベントをスケジュールするために前記メモリコントローラがシステムオンチップ上の複数のプロセッサの各々に信号を提供するステップと、
    前記信号に応答して前記複数のプロセッサの各々が独立して前記保守イベントのための対応するスケジュール通知を生成するステップと、
    前記複数のプロセッサによって生成された前記スケジュール通知のうちの1つまたは複数を受信することに応答して、またプロセッサ優先順位方式に基づいて、前記メモリコントローラが前記保守イベントをいつ実行するかを決定するステップと
    を含む、方法。
  2. 前記メモリコントローラが前記保守イベントをいつ実行するかを決定するステップが、各スケジュール通知が受信されるときに1つまたは複数の決定ルールを適用するステップを含み、前記1つまたは複数の決定ルールが、現在のプロセッサ負荷、現在のプロセッサ優先順位、および前記メモリデータインターフェース上の測定された利用率のうちの1つまたは複数に基づいている、請求項1に記載の方法。
  3. 前記メモリコントローラが前記保守イベントをいつ実行するかを決定するステップが、
    前記複数のプロセッサのうちの第1のプロセッサから現在のスケジュール通知を受信するステップと、
    前記現在のスケジュール通知に関連付けられたプロセッサ優先順位を決定するステップと、
    前記現在の通知の前記プロセッサ優先順位よりも高い優先順位を有する未処理のスケジュール通知がある場合、前記複数のプロセッサのうちの別のプロセッサから次のスケジュール通知を受信するのを待つステップと、
    前記現在のスケジュール通知の前記プロセッサ優先順位よりも前記高い優先順位を有する未処理のスケジュール通知がない場合、メモリトラフィック利用が所定のしきい値を下回るとき、前記保守イベントを実行するステップと
    を含む、請求項1に記載の方法。
  4. 前記複数のプロセッサが、中央処理装置(CPU)、グラフィックス処理装置(GPU)、およびモデムプロセッサを含む、請求項1に記載の方法。
  5. 前記プロセッサ優先順位方式が、前記複数のプロセッサの各々に優先順位を割り当てる、請求項1に記載の方法。
  6. 前記ToSウィンドウの間に前記揮発性メモリデバイスに対して前記保守イベントを実行するステップ
    をさらに含む、請求項1に記載の方法。
  7. 前記プロセッサに提供される前記信号が、割込み信号を含み、前記複数のプロセッサによって生成される前記スケジュール通知が、プロセッサ識別子、プロセッサ優先順位、プロセッサ負荷、および保守イベントタイプのうちの1つまたは複数を含む書込みコマンドを含む、請求項1に記載の方法。
  8. 前記揮発性メモリデバイスが、ダイナミックランダムアクセスメモリ(DRAM)デバイスを含み、前記保守イベントが、前記DRAMデバイスにサービスするための、リフレッシュ動作、較正動作、およびトレーニング動作のうちの1つまたは複数を含む、請求項1に記載の方法。
  9. 揮発性メモリ保守イベントをスケジュールするためのシステムであって、
    メモリデータインターフェースを介してメモリコントローラに結合される揮発性メモリデバイスに対して保守イベントを実行するためにタイムオブサービス(ToS)ウィンドウを決定するための手段と、
    前記保守イベントをスケジュールするために、システムオンチップ(SoC)上の複数のプロセッサの各々に信号を提供するための手段と、
    前記信号に応答して前記複数のプロセッサの各々が独立して前記保守イベントのための対応するスケジュール通知を生成するための手段と、
    前記複数のプロセッサによって生成された前記スケジュール通知のうちの1つまたは複数を受信することに応答して、またプロセッサ優先順位方式に基づいて、前記保守イベントをいつ実行するかを決定するための手段と
    を含む、システム。
  10. 前記保守イベントをいつ実行するかを決定するための前記手段が、各スケジュール通知が受信されるときに1つまたは複数の決定ルールを適用するための手段を含み、前記1つまたは複数の決定ルールが、現在のプロセッサ負荷、現在のプロセッサ優先順位、および前記メモリデータインターフェース上の測定された利用率のうちの1つまたは複数に基づいている、請求項9に記載のシステム。
  11. 前記保守イベントをいつ実行するかを決定するための前記手段が、
    前記複数のプロセッサのうちの第1のプロセッサから現在のスケジュール通知を受信するための手段と、
    前記現在のスケジュール通知に関連付けられたプロセッサ優先順位を決定するための手段と、
    前記現在のスケジュール通知の前記プロセッサ優先順位よりも高い優先順位を有する未処理のスケジュール通知がある場合、前記複数のプロセッサのうちの別のプロセッサから次のスケジュール通知を受信するのを待つための手段と、
    前記現在のスケジュール通知の前記プロセッサ優先順位よりも前記高い優先順位を有する未処理のスケジュール通知がない場合、メモリトラフィック利用が所定のしきい値を下回るとき、前記保守イベントを実行するための手段と
    を含む、請求項9に記載のシステム。
  12. 前記複数のプロセッサが、中央処理装置(CPU)、グラフィックス処理装置(GPU)、およびモデムプロセッサを含む、請求項9に記載のシステム。
  13. 前記プロセッサ優先順位方式が、前記複数のプロセッサの各々に優先順位を割り当てる、請求項9に記載のシステム。
  14. 前記ToSウィンドウの間に前記揮発性メモリデバイスに対して前記保守イベントを実行するための手段
    をさらに含む、請求項9に記載のシステム。
  15. 前記揮発性メモリデバイスが、ダイナミックランダムアクセスメモリ(DRAM)デバイスを含み、前記保守イベントが、前記DRAMデバイスにサービスするための、リフレッシュ動作、較正動作、およびトレーニング動作のうちの1つまたは複数を含む、請求項9に記載のシステム。
  16. メモリ内で具現化され、揮発性メモリ保守イベントをスケジュールするためにプロセッサによって実行可能である、コンピュータプログラムであって、
    メモリデータインターフェースを介してメモリコントローラに結合される揮発性メモリデバイスに対して保守イベントを実行するためにタイムオブサービス(ToS)ウィンドウを決定することと、
    システムオンチップ(SoC)上の複数のプロセッサの各々に割込み信号を提供することと、
    前記複数のプロセッサによって独立して生成された1つまたは複数のスケジュール通知を受信することに応答して、またプロセッサ優先順位方式に基づいて、前記保守イベントをいつ実行するかを決定することと
    を行うように構成される論理手段を含む、コンピュータプログラム。
  17. 前記保守イベントをいつ実行するかを決定するように構成される前記論理手段が、各スケジュール通知が受信されるとき、1つまたは複数の決定ルールを適用するように構成される論理手段を含み、前記1つまたは複数の決定ルールが、現在のプロセッサ負荷、現在のプロセッサ優先順位、および前記メモリデータインターフェース上の測定された利用率のうちの1つまたは複数に基づいている、請求項16に記載のコンピュータプログラム。
  18. 前記保守イベントをいつ実行するかを決定するように構成される前記論理手段が、
    前記複数のプロセッサのうちの第1のプロセッサから現在のスケジュール通知を受信することと、
    前記現在のスケジュール通知に関連付けられたプロセッサ優先順位を決定することと、
    前記現在のスケジュール通知の前記プロセッサ優先順位よりも高い優先順位を有する未処理のスケジュール通知がある場合、前記複数のプロセッサのうちの別のプロセッサから次のスケジュール通知を受信するのを待つことと、
    前記現在のスケジュール通知の前記プロセッサ優先順位よりも前記高い優先順位を有する未処理のスケジュール通知がない場合、メモリトラフィック利用が所定のしきい値を下回るとき、前記保守イベントを実行することと
    を行うように構成される論理手段を含む、請求項16に記載のコンピュータプログラム。
  19. 前記複数のプロセッサが、中央処理装置(CPU)、グラフィックス処理装置(GPU)、およびモデムプロセッサを含む、請求項16に記載のコンピュータプログラム。
  20. 前記プロセッサ優先順位方式が、前記複数のプロセッサの各々に優先順位を割り当てる、請求項16に記載のコンピュータプログラム。
  21. 前記ToSウィンドウの間に前記揮発性メモリデバイスに対して前記保守イベントを実行する
    ように構成される論理手段をさらに含む、請求項16に記載のコンピュータプログラム。
  22. 前記揮発性メモリデバイスが、ダイナミックランダムアクセスメモリ(DRAM)デバイスを含み、前記保守イベントが、前記DRAMデバイスにサービスするための、リフレッシュ動作、較正動作、およびトレーニング動作のうちの1つまたは複数を含む、請求項16に記載のコンピュータプログラム。
  23. 揮発性メモリ保守イベントをスケジュールするためのシステムであって、
    ダイナミックランダムアクセスメモリ(DRAM)デバイスと、
    複数のプロセッサ、およびメモリデータインターフェースを介して前記DRAMデバイスに電気的に結合されるDRAMコントローラを含むシステムオンチップ(SoC)であって、前記DRAMコントローラが、
    前記DRAMデバイスに対して保守イベントを実行するためにタイムオブサービス(ToS)ウィンドウを決定することであって、前記ToSウィンドウが、前記複数のプロセッサの各々に提供される信号、および前記保守イベントを実行するためのデッドラインによって定義される、決定することと、
    前記信号に応答して、またプロセッサ優先順位方式に基づいて、前記複数のプロセッサによって独立して生成されたスケジュール通知を受信することに応答して、前記保守イベントをいつ実行するかを決定することと
    を行うように構成される論理手段を含む、SoCと
    を含む、システム。
  24. 前記保守イベントをいつ実行するかを決定するように構成される前記論理手段が、各スケジュール通知が受信されるときに1つまたは複数の決定ルールを適用するように構成される論理手段を含み、前記1つまたは複数の決定ルールが、現在のプロセッサ負荷、現在のプロセッサ優先順位、および前記メモリデータインターフェース上の測定された利用率のうちの1つまたは複数に基づいている、請求項23に記載のシステム。
  25. 前記保守イベントをいつ実行するかを決定するように構成される前記論理手段が、
    前記複数のプロセッサのうちの第1のプロセッサから現在のスケジュール通知を受信することと、
    前記現在のスケジュール通知に関連付けられたプロセッサ優先順位を決定することと、
    前記現在のスケジュール通知の前記プロセッサ優先順位よりも高い優先順位を有する未処理のスケジュール通知がある場合、前記複数のプロセッサのうちの別のプロセッサから次のスケジュール通知を受信するのを待つことと、
    前記現在のスケジュール通知の前記プロセッサ優先順位よりも前記高い優先順位を有する未処理のスケジュール通知がない場合、メモリトラフィック利用が所定のしきい値を下回るとき、前記保守イベントを実行することと
    を行うように構成される論理手段を含む、請求項23に記載のシステム。
  26. 前記複数のプロセッサが、中央処理装置(CPU)、グラフィックス処理装置(GPU)、およびモデムプロセッサを含む、請求項23に記載のシステム。
  27. 前記プロセッサ優先順位方式が、前記複数のプロセッサの各々に優先順位を割り当てる、請求項23に記載のシステム。
  28. 前記DRAMコントローラが、前記ToSウィンドウの間に前記保守イベントを実行するように構成される論理手段をさらに含む、請求項23に記載のシステム。
  29. 前記プロセッサに提供される前記信号が、割込み信号を含み、前記割込み信号に応答して前記複数のプロセッサによって生成される前記スケジュール通知が、プロセッサ識別子、プロセッサ優先順位、プロセッサ負荷、および保守イベントタイプのうちの1つまたは複数を含む書込みコマンドを含む、請求項23に記載のシステム。
  30. 前記DRAMデバイスおよび前記SoCが、ポータブルコンピューティングデバイスに設けられ、前記保守イベントが、前記DRAMデバイスにサービスするための、リフレッシュ動作、較正動作、およびトレーニング動作のうちの1つまたは複数を含む、請求項23に記載のシステム。
JP2017541063A 2015-02-13 2016-02-05 マルチプロセッサシステムにおける揮発性メモリ保守イベントのスケジューリング Pending JP2018508886A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US14/622,017 US20160239442A1 (en) 2015-02-13 2015-02-13 Scheduling volatile memory maintenance events in a multi-processor system
US14/622,017 2015-02-13
PCT/US2016/016876 WO2016130440A1 (en) 2015-02-13 2016-02-05 Scheduling volatile memory maintenance events in a multi-processor system

Publications (1)

Publication Number Publication Date
JP2018508886A true JP2018508886A (ja) 2018-03-29

Family

ID=55451570

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017541063A Pending JP2018508886A (ja) 2015-02-13 2016-02-05 マルチプロセッサシステムにおける揮発性メモリ保守イベントのスケジューリング

Country Status (5)

Country Link
US (1) US20160239442A1 (ja)
EP (1) EP3256951A1 (ja)
JP (1) JP2018508886A (ja)
CN (1) CN107209736A (ja)
WO (1) WO2016130440A1 (ja)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010085405A1 (en) * 2009-01-22 2010-07-29 Rambus Inc. Maintenance operations in a dram
US9989960B2 (en) 2016-01-19 2018-06-05 Honeywell International Inc. Alerting system
EP3264276A1 (en) * 2016-06-28 2018-01-03 ARM Limited An apparatus for controlling access to a memory device, and a method of performing a maintenance operation within such an apparatus
US9857978B1 (en) 2017-03-09 2018-01-02 Toshiba Memory Corporation Optimization of memory refresh rates using estimation of die temperature
US10503546B2 (en) 2017-06-02 2019-12-10 Apple Inc. GPU resource priorities based on hardware utilization
US20190026028A1 (en) * 2017-07-24 2019-01-24 Qualcomm Incorporated Minimizing performance degradation due to refresh operations in memory sub-systems
US10795730B2 (en) 2018-09-28 2020-10-06 Apple Inc. Graphics hardware driven pause for quality of service adjustment
EP3912034A1 (en) * 2019-01-14 2021-11-24 Telefonaktiebolaget LM Ericsson (publ) Methods for event prioritization in network function virtualization using rule-based feedback

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6463001B1 (en) * 2000-09-15 2002-10-08 Intel Corporation Circuit and method for merging refresh and access operations for a memory device
US7020741B1 (en) * 2003-04-29 2006-03-28 Advanced Micro Devices, Inc. Apparatus and method for isochronous arbitration to schedule memory refresh requests
US7930471B2 (en) * 2004-11-24 2011-04-19 Qualcomm Incorporated Method and system for minimizing impact of refresh operations on volatile memory performance
US7454632B2 (en) * 2005-06-16 2008-11-18 Intel Corporation Reducing computing system power through idle synchronization
US7613941B2 (en) * 2005-12-29 2009-11-03 Intel Corporation Mechanism for self refresh during advanced configuration and power interface (ACPI) standard C0 power state
US8458386B2 (en) * 2010-12-07 2013-06-04 Apple Inc. Atomic interrupt masking in an interrupt controller to prevent delivery of same interrupt vector for consecutive interrupt acknowledgements
US9432298B1 (en) * 2011-12-09 2016-08-30 P4tents1, LLC System, method, and computer program product for improving memory systems
US9141561B2 (en) * 2012-10-25 2015-09-22 Texas Instruments Incorporated Master circuits having dynamic priority leads coupled with memory controller

Also Published As

Publication number Publication date
WO2016130440A1 (en) 2016-08-18
CN107209736A (zh) 2017-09-26
WO2016130440A9 (en) 2017-09-08
US20160239442A1 (en) 2016-08-18
EP3256951A1 (en) 2017-12-20

Similar Documents

Publication Publication Date Title
JP2018508886A (ja) マルチプロセッサシステムにおける揮発性メモリ保守イベントのスケジューリング
US10606653B2 (en) Efficient priority-aware thread scheduling
US9626295B2 (en) Systems and methods for scheduling tasks in a heterogeneous processor cluster architecture using cache demand monitoring
US10437639B2 (en) Scheduler and CPU performance controller cooperation
US8959402B2 (en) Method for preemptively restarting software in a multi-subsystem mobile communication device to increase mean time between failures
JP6423518B2 (ja) マルチプロセッサシステムのための指向性イベントシグナリング
EP3268842B1 (en) Methods and systems for coordination of operating states amongst multiple socs within a computing device
EP2831734A2 (en) Apparatus and methods for a bandwidth efficient scheduler
US10564708B2 (en) Opportunistic waking of an application processor
TW201342027A (zh) 於動作工作負載期間動態進入低功率狀態
KR20210135929A (ko) Nr v2x의 모드 2 리소스 선택 절차에서 최소 후보 리소스들의 비율을 동적으로 변경하는 방법
US9355049B2 (en) Interrupt monitoring system and computer system
EP3256952B1 (en) Systems and methods for providing kernel scheduling of volatile memory maintenance events
US11221875B2 (en) Cooperative scheduling of virtual machines
US9618988B2 (en) Method and apparatus for managing a thermal budget of at least a part of a processing system
US9785586B2 (en) Electronic computer and interrupt control method
WO2022204873A1 (zh) 电子装置、系统级芯片和物理核分配方法
CN116225672A (zh) 基于众核芯片的任务处理方法及装置、处理核、电子设备
JP5494925B2 (ja) 半導体集積回路、情報処理装置およびプロセッサ性能保証方法
CN113722078A (zh) 一种基于线程池高并发数据库访问方法、系统及设备