Thread context restoration in a multithreading computer system
20 claims: 5 independent, 15 dependent
- 1コンピュータ・システムであって、 シングル・スレッド(ST)モードとマルチスレッディング(MT)モードとの間で切換え構成可能なコアを含む構成であって、前記STモードは一次スレッドを扱い、前記MTモードは前記一次スレッドと前記コアの共用資源上の1つまたは複数の二次スレッドとを扱う、前記構成と、 前記構成の利用を制御して方法を実行するよう構成されたマルチスレッディング機構とを含み、 前記方法は、 前記構成のリセットまたは非活動化に応答した前記MTモードから前記STモードへの切換えに基づいて、前記1つまたは複数の二次スレッドのプログラム・アクセス可能レジスタ値とプログラム・カウンタ値とを含むスレッド・コンテキストをプログラムが利用することができないようにして前記1つまたは複数の二次スレッドを無効化することと、 前記1つまたは複数の二次スレッドの前記スレッド・コンテキストが前記切換え後にアクセス可能であるか否かを示す前記構成の直前設定プログラム指定最大スレッドidを判断するために、前記STモードで実行中に直前指定最大MTレベルを問い合わせることと、 前記直前設定プログラム指定最大スレッドidが、前記1つまたは複数の二次スレッドの前記スレッド・コンテキストが前記切換え後にアクセス可能であることを示していることに基づいて、 a)前記MTモードを再開するためにMT設定命令(instruction)を実行すること、および b)再開された前記MTモードになっていることに基づいて前記1つまたは複数の二次スレッドの前記スレッド・コンテキストにアクセスすること、 を実行することによって前記1つまたは複数の二次スレッドの前記スレッド・コンテキストを取得することとを含む、コンピュータ・システム。
- 2前記MT設定命令(instruction)は、MT設定命令(order)とMTを示すプログラム指定最大スレッドidとを含むシグナル・プロセッサ命令である、請求項1に記載のコンピュータ・システム。
- 3前記STモードへの切換えに基づいて前記1つまたは複数の二次スレッドの前記スレッド・コンテキストをセーブすることをさらに含む、請求項1に記載のコンピュータ・システム。
- 4前記MTモードから前記STモードへの切換えは非クリア・リセット動作に応答しており、前記MTモードを再開するための前記MT設定命令(instruction)の実行と、前記1つまたは複数の二次スレッドの前記スレッド・コンテキストへのアクセスとがスタンドアロン・ダンプ・プログラムによって行われる、請求項1に記載のコンピュータ・システム。
- 5前記MTモードを再開するためにMT設定命令(order)を発行する際に、前記スタンドアロン・ダンプ・プログラムが前記直前 設定 プログラム指定最大スレッドidをプログラム指定最大スレッドidとして指定する、請求項4に記載のコンピュータ・システム。
- 6ス タンドアロン・ダンプ・プログラムが前記構成から二次スレッドのダンプを試みるのを防止するために、前記構成においてMTをサポートしないオペレーティング・システムをロードする前にクリア・リセットが実行される、請求項1に記載のコンピュータ・システム。
- 7前記構成のためにスタンドアロン・ダンプ・プログラムを実行する前に、 M Tを利用しない 制御 プログラムが、 プログラム指定最大スレッドidとして単一スレッドを示す値 とともにMT設定命令(order)を発行する、請求項1に記載のコンピュータ・システム。
- 8前記直前 設定 プログラム指定最大スレッドidは、前記構成のクリア・リセットまたは非活動化が行われるまで保持される、請求項1に記載のコンピュータ・システム。
- 9シングル・スレッド(ST)モードとマルチスレッディング(MT)モードとの間で切換え構成可能なコアを含む構成においてスレッド・コンテキストを復元するためのコンピュータ実装方法であって、前記STモードは一次スレッドを扱い、前記MTモードは前記一次スレッドと前記コアの共用資源上の1つまたは複数の二次スレッドとを扱い、前記方法は、 前記構成のリセットまたは非活動化に応答した前記MTモードから前記STモードへの切換えに基づいて、前記1つまたは複数の二次スレッドのプログラム・アクセス可能レジスタ値とプログラム・カウンタ値とを含むスレッド・コンテキストをプログラムが利用することができないようにして前記1つまたは複数の二次スレッドを無効化することと、 前記1つまたは複数の二次スレッドの前記スレッド・コンテキストが前記切換え後にアクセス可能であるか否かを示す前記構成の直前設定プログラム指定最大スレッドidを判断するために、前記STモードで実行中に直前指定最大MTレベルを問い合わせることと、 前記直前設定プログラム指定最大スレッドidが、前記1つまたは複数の二次スレッドの前記スレッド・コンテキストが前記切換え後にアクセス可能であることを示していることに基づいて、 a)前記MTモードを再開するためにMT設定命令(instruction)を実行すること、および b)再開された前記MTモードになっていることに基づいて前記1つまたは複数の二次スレッドの前記スレッド・コンテキストにアクセスすること、 を実行することによって前記1つまたは複数の二次スレッドの前記スレッド・コンテキストを取得することとを含む、コンピュータ実装方法。
- 10前記MT設定命令(instruction)は、MT設定命令(order)とMTを示すプログラム指定最大スレッドidとを含むシグナル・プロセッサ命令である、請求項9に記載の方法。
- 11前記STモードへの切換えに基づいて前記1つまたは複数の二次スレッドの前記スレッド・コンテキストをセーブすることをさらに含む、請求項9に記載の方法。
- 12前記MTモードから前記STモードへの切換えは非クリア・リセット動作に応答しており、前記MTモードを再開するための前記MT設定命令(instruction)の実行と、前記1つまたは複数の二次スレッドの前記スレッド・コンテキストへのアクセスとがスタンドアロン・ダンプ・プログラムによって行われる、請求項9に記載の方法。
- 13前記MTモードを再開するためにMT設定命令(order)を発行する際に、前記スタンドアロン・ダンプ・プログラムが前記直前 設定 プログラム指定最大スレッドidをプログラム指定最大スレッドidとして指定する、請求項12に記載の方法。
- 14ス タンドアロン・ダンプ・プログラムが前記構成から二次スレッドのダンプを試みるのを防止するために、前記構成においてMTをサポートしないオペレーティング・システムをロードする前にクリア・リセットが実行される、請求項9に記載の方法。
- 15前記構成のためにスタンドアロン・ダンプ・プログラムを実行する前に、 M Tを利用しない 制御 プログラムが、 単一スレッドを示す値をプログラム指定最大スレッドidとして指定した MT設定命令(order)を発行する、請求項9に記載の方法。
- 16シングル・スレッド(ST)モードとマルチスレッディング(MT)モードとの間で切換え構成可能なコアを含む構成においてスレッド・コンテキストを復元するためのコンピュータ・プログラ ム であって、前記STモードは一次スレッドを扱い、前記MTモードは前記一次スレッドと前記コアの共用資源上の1つまたは複数の二次スレッドとを扱い、前記コンピュータ・プログラムはコンピュータに、 前記構成のリセットまたは非活動化に応答した前記MTモードから前記STモードへの切換えに基づいて、前記1つまたは複数の二次スレッドのプログラム・アクセス可能レジスタ値とプログラム・カウンタ値とを含むスレッド・コンテキストをプログラムが利用することができないようにして前記1つまたは複数の二次スレッドを無効化することと、 前記1つまたは複数の二次スレッドの前記スレッド・コンテキストが前記切換え後にアクセス可能であるか否かを示す前記構成の直前設定プログラム指定最大スレッドidを判断するために、前記STモードで実行中に直前指定最大MTレベルを問い合わせることと、 前記直前設定プログラム指定最大スレッドidが、前記1つまたは複数の二次スレッドの前記スレッド・コンテキストが前記切換え後にアクセス可能であることを示していることに基づいて、 a)前記MTモードを再開するためにMT設定命令(instruction)を実行すること、および b)再開された前記MTモードになっていることに基づいて前記1つまたは複数の二次スレッドの前記スレッド・コンテキストにアクセスすること、 を実行することによって前記1つまたは複数の二次スレッドの前記スレッド・コンテキストを取得することと を 実行させる、コンピュータ・プログラム。
- 17前記MT設定命令(instruction)は、MT設定命令(order)オーダとMTを示すプログラム指定最大スレッドidとを含むシグナル・プロセッサ命令である、請求項16に記載のコンピュータ・プログラム。
- 18前記STモードへの切換えに基づいて前記1つまたは複数の二次スレッドの前記スレッド・コンテキストをセーブすることをさらに前記コンピュータに実行させる、請求項16に記載のコンピュータ・プログラム。
- 19前記MTモードから前記STモードへの切換えは非クリア・リセット動作に応答しており、前記MTモードを再開するための前記MT設定命令(instruction)の実行と、前記1つまたは複数の二次スレッドの前記スレッド・コンテキストへのアクセスとがスタンドアロン・ダンプ・プログラムによって行われる、請求項16に記載のコンピュータ・プログラム。
- 20前記直前 設定 プログラム指定最大スレッドidは、前記構成のクリア・リセットまたは非活動化が行われるまで保持される、請求項16に記載のコンピュータ・プログラム。
Independent claims20
98 paragraphs, as filed
The present invention relates generally to computer systems that support multiple threads, and more specifically to thread context restoration in multithreaded computer systems.
Although the processor speed of computer systems has increased in recent decades, the speed of access to memory of such computer systems has not increased accordingly. Therefore, the faster the processor cycle time, the greater the delay in waiting for data fetch from memory. The effects of such delays have been mitigated by various levels of caching, and more recently by multithreading (MT) in modern processors.
MT allows various core resources of a processor to be shared by multiple instruction streams called threads. Core resources can include execution units, caches, translation lookaside buffers (TLBs), etc., which are commonly referred to as cores. During latency caused by cache misses or other delays in one thread, one or more other threads can use the core resource, which increases the utilization of the core resource. The Superscalar Processor Simultaneous Multithreading (SMT) implementation allows multiple threads to be addressed simultaneously by the core resources of one or more cores.
<p><nplcit num="1"><text>"Z / Architecture Principles of Operation" (IBM Publication No. SA22-7832-09, August 2012)</text></nplcit></p>
<p> On current hardware platforms, MT is typically implemented in a transparent manner to the operating system (OS) running on MT hardware. One aspect of this feature is that the OS does not require any changes to take advantage of MT hardware. However, OS-transparent MT behavior can increase response time, capacity provisioning, capacity planning, and billing volatility. This variability can occur because the OS does not know if the OS task has exclusive control over the core or if the OS task is running as a thread that shares the core. By design, maximum capacity for memory-intensive workloads on MT-enabled hardware can be achieved when the average thread density is high when using the core. Increased cache usage caused by MT may result in additional capacity. If the OS does not maintain a constant high average thread density of the cores used, it will not be able to take advantage of the additional processing power generated by MT. For example, if the hardware runs one MT thread per core at low math usage and runs at high thread density at high math usage, how much total MT math for the workload Determining if capacity is available can be extremely difficult. Similar to the capacity mentioned above, this hardware volatility in MT thread utilization can result in volatility in both transaction response time and billing.</p>
<p> Embodiments include systems, methods, and computer program products for thread context restoration in multithreaded computer systems. One aspect is a configuration including a core capable of switching between single thread (ST) mode and multithreading (MT) mode. ST mode handles the primary thread, and MT mode handles the primary thread and one or more secondary threads on the shared resource of the core. A multithreading mechanism is configured to control the utilization of the configuration and perform methods that include disabling one or more secondary threads based on switching from MT mode to ST mode. Prevents a program from being used in a thread context that contains program-accessible register values and program counter values for one or more secondary threads. Inquire about the maximum MT level specified immediately before in ST mode in order to determine the maximum thread id specified by the program specified immediately before the configuration. Based on the fact that the maximum thread id specified by the last-minute setting program indicates MT mode, a) the MT setting instruction (instruction) is executed to restart MT mode, and b) the restarted MT mode is set. Obtain the thread context of one or more secondary threads by accessing and executing the thread context of one or more secondary threads based on.</p><p> According to another aspect, a computer implementation method for restoring the thread context in the configuration is provided. The configuration includes cores that can be switched between single-threaded (ST) mode and multithreaded (MT) mode, ST mode handles the primary thread, and MT mode handles the primary thread and 1 on the core's shared resources. Handle with one or more secondary threads. The method involves disabling one or more secondary threads based on switching from MT mode to ST mode. Makes a thread context unavailable to a program that contains program-accessible register values and program counter values for one or more secondary threads. Inquire about the maximum MT level specified immediately before in ST mode to determine the maximum thread id specified by the program specified immediately before the configuration. Based on the fact that the maximum thread id specified by the last-minute setting program indicates MT, a) the MT setting instruction (instruction) is executed to restart MT mode, and b) the restarted MT mode is set. Gets the thread context of one or more secondary threads by accessing and executing the thread context of one or more secondary threads based on.</p><p> Yet another aspect includes a computer program product for restoring thread context in the configuration. The configuration includes cores that can be switched between single-threaded (ST) mode and multithreaded (MT) mode, ST mode handles primary threads, and MT mode handles primary threads and 1 on the core's shared resources. Handle with one or more secondary threads. This computer program product includes a computer-readable storage medium in which program instructions are embodied, and the computer-readable storage medium is not a signal. The program instruction can be read by the processing circuit to cause the processing circuit to execute the method. The method involves disabling one or more secondary threads based on switching from MT mode to ST mode. Prevents a program from being used in a thread context that contains program-accessible register values and program counter values for one or more secondary threads. Inquire about the maximum MT level specified immediately before in ST mode in order to determine the maximum thread id specified by the program specified immediately before the configuration. Based on the fact that the maximum thread id specified by the last-minute setting program indicates MT, a) the MT setting instruction (instruction) is executed to restart MT mode, and b) the restarted MT mode is set. Gets the thread context of one or more secondary threads by accessing and executing accessing the thread context of one or more secondary threads based on.</p><p> The subject matter considered to be an embodiment is specifically indicated and explicitly claimed within the appended claims. The above and other features and advantages of the embodiments will become apparent when the following detailed description is read with the accompanying drawings.</p>
<figref num="1">It is a figure which shows the computing environment which can be implemented by one Embodiment.</figref><figref num="2">It is a figure which shows the computing environment which can be implemented by one Embodiment.</figref><figref num="3">It is a figure which shows the processing circuit of the core which can be implemented by one Embodiment.</figref><figref num="4">It is a figure which shows the computing environment which can be implemented by one Embodiment.</figref><figref num="5">It is a figure which shows the hypervisor context holding in the computing environment which can be carried out by one Embodiment.</figref><figref num="6">It is a figure which shows the flow of the dynamic activation processing of multithreading by one Embodiment.</figref><figref num="7">It is a figure which shows an example of the CPU address extension processing by one Embodiment.</figref><figref num="8">It is a figure which shows an example of the CPU address reduction processing by one Embodiment.</figref><figref num="9">It is a figure which shows the flow of the process of the multithreading setting instruction (order) by one Embodiment.</figref><figref num="10">It is a figure which shows an example of the storage of the multithreading function information by one Embodiment.</figref><figref num="11">It is a figure which shows the flow of the process for determining the multithreading function by one Embodiment.</figref><figref num="12">It is a figure which shows an example of various thread context storage locations by one Embodiment.</figref><figref num="13">It is a figure which shows an example of multithreading register preservation by one Embodiment.</figref><figref num="14">It is a figure which shows the flow of the multithreading register preservation processing by one Embodiment.</figref><figref num="15">It is a figure which shows an example of multithreading register restoration by one Embodiment.</figref><figref num="16">It is a figure which shows the flow of the multithreading register restoration processing by one Embodiment.</figref><figref num="17">It is a figure which shows the computer readable medium by one Embodiment.</figref>
An exemplary embodiment provides multithreading operation in a computer system that supports single-threaded operation mode and multithreading operation mode. As used herein, a logical thread refers to a single instruction stream and its associated state. That is, at the architecture level, each logical thread represents an independent central processing unit (CPU) or processor. At the hardware level, a thread is the execution of an instruction stream associated with a logical thread combined with maintaining guest state when the thread is dispatched. Therefore, the terms "thread" and "CPU" may be used interchangeably herein.
In one exemplary embodiment, the CPU comprises an ordering and processing mechanism for instruction execution, interrupt operation, timing functions, initial program loading, and other machine-related functions. The CPU defines logical functions that can be associated with various underlying physical implementations. The CPU processes fixed-length binary and floating-point numbers (eg, binary, decimal and hexadecimal), variable-length decimal integers, and fixed-length or variable-length logical information when executing instructions. can do. The processing can be parallel or sequential processing. The width of processing elements, the multiplicity of shift paths, and the degree of concurrency in different types of arithmetic processing may differ depending on the CPU model, but they do not affect the logical result.
The instructions that the CPU executes are general-purpose instructions, floating-point support (FPS) instructions, binary floating-point (BFP) instructions, decimal floating-point (DFP) instructions, hexadecimal floating-point (HFP) instructions, control instructions, and I. It can contain multiple instruction classes, such as the / O instruction. General instructions can be used to perform binary integer arithmetic and logical operations, branch operations and other non-arithmetic operations. Decimal instructions work on decimal data. BFP, DFP, and HFP instructions work on data in BFP, DFP, and HFP formats, respectively, and FPS instructions work on floating-point data that is independent of format, or from one format to another. Convert to. According to the appropriate authorization mechanism, privileged control instructions and I / O instructions can be executed when the CPU is in the supervisor state, and quasi-privileged control instructions can be executed when the CPU is in the problem state.
The CPU provides registers that are available to the program but do not have an addressable representation in main memory. The registers are, for example, the current program state word (PSW), the general purpose register, the floating point register, the floating point control register, the vector register, the control register, the access register, the prefix register, and the time ( TOD) Programmable registers may include registers for clock comparators and CPU timers. This set of registers is sometimes referred to as the CPU's Architected Register context. Each CPU in the configuration can have access to the TOD clock, which can be shared by all CPUs in the configuration. The instruction operation code can determine which type of register is used in an operation.
Each CPU can have a type attribute that indicates whether the CPU provides full functionality and mechanics (eg, a general purpose CPU) or is intended for processing a special type of workload (eg, a special CPU). The primary CPU is a general purpose CPU or a CPU of the same type as the CPU (IPL CPU) that is started after the last initial program load (IPL) operation. The secondary CPU is a CPU other than a general-purpose CPU that has a CPU type different from that of the IPL CPU.
Multithreading mechanisms may be available on computer systems that implement the supported architectures. The multithreading mechanism provides support for multithreading, allowing groups of threads that share a core, sometimes referred to as the CPU. When the multithreading mechanism is enabled, CPUs in the core can share certain hardware resources such as execution units or caches. If one CPU in the core is waiting for a hardware resource (typically while waiting for memory access), the other CPU in that core will not leave the shared resource idle. Shared resources can be used. If the multithreading mechanism is installed and enabled, threads are synonymous with CPUs that belong to the core. If the multithreading mechanism is not installed, or if the multithreading mechanism is installed but not enabled, the core contains a single CPU or thread.
If the multithreading mechanism is installed, the multithreading mechanism can be enabled by executing the multithreading configuration signal processor (SIGP) instruction (order). In one embodiment of the example, when the multithreading mechanism is enabled, the number of CPUs in the configuration is increased by a multiple, and the value of the multiple is determined by the program-specified maximum thread identification information (PSMTID). The number of CPUs in the core may be higher than the PSM TID. The number of CPUs corresponding to this multiple is grouped into one core. Each core of the same CPU type in the configuration can have the same number of CPUs. Each CPU in the core has the same CPU type. However, depending on the model and CPU type, some CPUs in the core may not be operational.
In one embodiment of the example, a control program such as the OS explicitly enables multithreading so that the configuration managed by the operating system (OS) can use multithreading. Alternatively, the hypervisor can enable multithreading, allowing the hypervisor's guests and their applications to benefit transparently. Application programs generally do not know if multithreading has been enabled. When multithreading is enabled, the CPU addresses of all CPUs in the configuration contain the core identity (or core ID) in the leftmost bit of the address and the thread identifier (thread ID or TID) in the rightmost bit of the address. Adjusted to include. The core ID is sometimes referred to as the core address value, and the TID is sometimes referred to as the thread address value. CPUs in a core can share certain hardware mechanisms such as execution units or lower-order caches, so execution within a CPU with a core affects the performance of other CPUs within that core. Sometimes.
Several support features are provided to manage the changes associated with dynamically switching one or more cores of the configuration between single-threaded mode and multithreaded mode. Single-threaded mode may be the default mode on reset or deactivation for compatibility with programs that do not support multithreading. Examples of embodiments include storing and transmitting thread contexts from multithreaded mode to support analysis and / or restoration of thread contexts after transition from multithreaded mode to singlethreaded mode. And has the ability to restore.
The computing environment that can be implemented by one of the exemplary embodiments can be based, for example, on z / Architecture provided by International Business Machines Corporation in Armonk, NY, USA. z / Architecture is listed in an IBM (R) publication entitled "z / Architecture Principles of Operation" (IBM Publication No. SA22-7832-09, August 2012). In one example, z / Architecture-based computing environments include the eServer zSeries provided by International Business Machines Corporation in Armonk, NY, USA. A computing environment is a processor complex with one or more partitions (eg, logical partitions) with, for example, one or more cores (eg, processor cores) and one or more as detailed herein. May include multiple levels of hypervisors.
Figure 1 shows the computer system 100 as an example of a computing environment that supports multithreading (MT). In the example of FIG. 1, the computer system 100 includes a plurality of processor cores 102, an input / output (I / O) subsystem 104, and system memory 106. The input / output subsystem 104 can provide access to I / O devices well known in the art. The processor core 102, also referred to herein simply as the "core," may include a processing circuit with supporting elements. In the example of FIG. 1, five cores 102 are illustrated as core 1 110, core 2 120, core 3 130, core 4 140, and core 5 150. However, more or less cores 102 are also contemplated. The MT mechanism 103 may be a hardware component of each core 102. In this example, each of the cores 102 can support up to 4 threads. For example, core 1 110 can support threads 111, 112, 113 and 114. Core 2 120 can support threads 121, 122, 123, and 124. Core 3 130 can support threads 131, 132, 133 and 134. Core 4 140 can support threads 141, 142, 143 and 144. Core 5 105 can support threads 151, 152, 153 and 154. Note that not all four threads of each CPU 102 are in the operating state at any time. For example, in core 3 130, threads 131 and 132 may be operational and threads 133 and 134 can be operational (shaded).
Figure 1 also illustrates the system memory 160 of computer system 100, where each part of system memory 160 is assigned to logical partition 1 (LPAR1) 170, LPAR2 180, and LPAR3 190. LPARs 170, 180, 190 are virtual computing systems (configurations) that can run operating systems such as Linux (TM) or IBM (R) z / OS (TM), z / VM, or zTPF operating systems. Also called). Figure 1 also shows the allocation of core 102 to LPARs 170, 180 and 190. In this figure, core 1 110 and core 2 120 are dedicated to LPAR1 170. Core 3 130 is dedicated to LPAR2 180 and Core 5 150 is dedicated to LPAR3 190. Core 4 140 can be shared between LPAR2 180 and LPAR3 190, but is shown in Figure 1 as assigned to LPAR2 180. LPAR3 190 shows two different types of examples of core 102 used by this partition, core 4 140 can run multiple threads, while core 5 150 runs multiple threads in this example. I can't let you. In the example of Figure 1, LPAR1 170 provides processing resources to OS171 and programs 172, 173, 174 and 175. LPAR2 180 provides processing resources for OS181 and programs 182, 183 and 184. LPAR4 190 provides processing resources for OS 191 and programs 192 and 193.
The program runs on the core thread under the control of the operating system running in the LPAR. In one embodiment of the example, each thread executes only one program at a time. However, programs designed to be reentrant may run on multiple threads or cores at the same time. For example, program 172 of OS171 of LPAR1 170 can be executed on threads 111 and 113 of core 1 110 and on threads 121 and 124 of core 2 120. Under OS control, different programs can be dispatched on the same or different threads according to dispatch rules and quality of service contracts.
System memory 160 resides with various levels of firmware, including, for example, millicode 162 and LPAR hypervisor 163. Millicode 162 can be implemented as firmware to support low levels of system functionality. The LPAR hypervisor 163 may be licensed internal code, for example IBM Processor-Resource / System Manager (TM) (PR / SM (TM)). LPAR hypervisor 163 is an LPAR 170, 180, 190 can be set, and dispatch on core 102 may be managed. If MT Mechanism 103 is installed on the computer, Millicode 162 and LPAR Hypervisor 163 also include MT Mechanism Support Codes 164 and 165, respectively. MT mechanism support codes 164 and 165 can be considered part of MT mechanism 103 because the logic to support MT can be distributed across the millicode 162, the LPAR hypervisor 163 and the core 102. Although not shown, each of OS171, 181, 191 can also include an MT mechanism support code to enable and utilize MT in their respective LPARs 170, 180, 190.
Figure 2 shows a computing system similar to Figure 1 except that Core 4 140 is currently assigned LPAR3 190 instead of LPAR2 180 in the computing environment of Figure 2. Also, unlike Figure 1, where threads 143 and 144 are not operational, in Figure 2, if LPAR3 190 is dispatched on core 4 140, all four threads 141-144 are currently operational. Is. Dispatching and undispatching LPARs on core 102 is dynamic, and at some point another LPAR (not shown) may be running on the same core 102.
Next, with reference to FIG. 3, a block diagram of a processing circuit 200 for mounting a processing core, such as one of the cores 102 in FIGS. 1 and 2, is schematically shown in one embodiment. .. The processing circuit 200 is an example of a processing circuit that can simultaneously support one or more threads in an MT environment. The processing circuit 200 shown in FIG. 3 includes a system controller interface unit 202 capable of connecting the processing circuit 200 to other processors and peripheral devices. The system controller interface unit 202 has a D cache 204 that reads and stores data values, an I cache 208 that reads program instructions, and a cache interface unit 206 as external memory, processors, and other peripheral devices. You can also connect to.
The I cache 208 can load an instruction stream in cooperation with an instruction fetch unit (IFU) 210 that prefetches instructions, and may have a speculative load function and a branch prediction function. The fetched instructions can be supplied to the instruction decoding unit (IDU) 212 for decoding to the instruction processing data.
IDU212 issues instructions to various execution units, such as one or more fixed-point units (FXU) 216 to perform general-purpose operations and floating-point units (FPU) 218 to perform floating-point operations. Instructions can be supplied to the issuing unit 214 that can be controlled. The FPU218 can include a binary floating point unit (BFU) 220, a decimal floating point unit (DFU) 222, or any other floating point unit. Issuing unit 214 can also be connected to one or more LSU 228s via one or more load / store unit (LSU) pipelines. Multiple LSU pipelines are treated as execution units for loading and storing and address generation for branching. Both LSU228 and IFU210 can utilize a translation lookaside buffer (TLB) 230 for buffer translation of operands and instruction addresses.
FXU216 and FPU218 can be connected to various resources such as general purpose register (GPR) 224 and floating point register (FPR) 226. The GPR224 and FPR226 provide data value storage for the data values loaded and stored from the D cache 204 by the LSU228.
The processing circuit 200 may also include a counter and / or timer 250 to support system time-based generation and diagnostic operations. For example, the counter and / or timer 250 may be used to support the time and various diagnostic and measurement functions.
Next, referring to FIG. 4, FIG. 4 illustrates a computing environment similar to FIG. 1 except that the second level hypervisor 300 is running on LPAR2 180 of computer system 100. The second level hypervisor 300, for example the IBM z / VM operating system, includes MT support code 301 similar to MT support code 165 provided by the LPAR (first level) hypervisor 163. The second level hypervisor 300 provides support for multiple virtual machines 310, 320 and 330 (also called configurations) running guest operating systems 311, 321 and 331, respectively. Guest operating systems 311, 321 and 331 are, for example, Linux (TM), or IBM (R) z / OS (TM), z / VM, or z / TPF. It may include an operating system or a guest development environment such as an IBM conversational monitor system (CMS). Each guest OS 311, 321 and 331 may or may not have multithreading enabled, in which case the second level hypervisor 300 is the physical processing available to the LPAR2 180 running the second level hypervisor 300. Even if it is responsible for dispatching guest OS311, 321, 331 and accompanying programs 312, 313, 322, 323, 332 and 333 using resources (core 130, 140 and threads 131-134, 141-144) Good. Programs 312, 322, 323, 332, 333 of the various virtual machines 310, 320, 330 can run on threads 131-134, 141-144, which are available for guest OS 311, 321 and 331, respectively. If the second level hypervisor 300 takes advantage of multithreading, guest OS311, 321 and 331 do not need to include the MT support code as they can transparently benefit from MT.
Next, with reference to FIG. 5, an example of hypervisor context retention in a computing environment that can be implemented by one embodiment is illustrated. In the example of FIG. 5, several support structures are illustrated within the LPAR hypervisor 163 of FIGS. 1 and 2. For example, structure 410 is currently running on logical threads 411, 412, 413, 414, 421, 422 on physical threads 111, 112, 113, 114, 121, 122, 123, 124, as shown in FIG. LPAR1 in Figure 1, which contains a state description block and a satellite block that store the architected register context (ie thread context) for, 423, 424. Can support 170. While these logical threads are dispatched, the physical threads hold the current architected register context of these threads. When undispatched, this architected register context will be held in the state description block and satellite block. Structure 430 is a state description that stores the architected register context for logical threads 431, 432, 441, 442 currently running on physical threads 131, 132, 141, 142, as shown in Figure 1. It can support LPAR2 180 in Figure 1, including blocks and satellite blocks. The structure 450 contains a state description block and a satellite block that store the architected register context for the logical thread 451 currently running on the physical thread 151, as shown in FIG. 1. LPAR3 Can support 190. Structure 450 also contains state-description and satellite blocks that store architected register contexts for logical threads 461, 462, 463, and 464 that are not currently dispatched on the physical processor (shaded). Also includes. Supports non-dispatched LPARs on physical cores, such as structure 470 for LPAR A (not shown in Figure 1), which contains state description blocks and satellite structures for logical threads 471, 472, 473 and 474. Other structures can also be held by the LPAR hypervisor 163. Still other examples of structures include structure 480, which supports undispatched LPAR B (not shown in Figure 1), which contains state-description blocks and satellite blocks for logical threads 481 and 482. There is a structure 484 for a non-dispatched LPAR C for logical thread 485.
Although some structures are illustrated in the example in Figure 5, it can be seen that additional structures can also be supported elsewhere in the LPAR hypervisor 163 and computer system 100 to manage multithreading. Will. For example, a structure for supporting multithreading of the virtual machines 310, 320, 330 of FIG. 4 can be held by the second level hypervisor 300 of FIG.
Next, referring to FIG. 6, a process flow 500 for dynamically enabling multithreading according to one embodiment is illustrated. At block 502, the primary thread runs in single thread (ST) mode. At block 504, the multithreading (MT) mode setting instruction is fetched in ST mode. When executing this instruction as collectively shown in 505, some requested threads are fetched in block 506 from the storage location specified by the MT mode setting instruction. This storage location can be specified by the parameter register when issuing the MT mode setting instruction. The MT mode setting instruction (instruction) can be a signal processor (SIGP) instruction including an MT setting instruction (order) and a program-specified maximum thread id (PSMTID) associated with the number of requested threads. An example of the processing associated with the MT setting instruction (order) of the SIGP instruction will be described in detail in this specification with reference to FIG.
Continuing the description of process 500, block 508 determines whether the number of request threads indicates multiple threads. For example, multiple threads can be indicated by a value greater than 1. In embodiments where the value zero indicates a single thread, multiple threads can be indicated by a value of 1 or a value greater than 1. Based on the determination that the number of requested threads does not indicate multiple threads, the core remains in ST mode at block 510, the execution of the MT configuration mode instruction is complete, and control returns to block 502. Based on the determination that the number of requested threads indicates multiple threads, MT mode is enabled in block 512 and the execution of the MT setting mode instruction is completed. At block 514, multiple threads are executed, including a primary thread and one or more secondary threads. If no reset or deactivation occurs at block 516, process 500 loops back to block 514. Otherwise, block 518 disables MT mode based on resetting or deactivating the configuration to return to ST mode. As part of disabling MT mode, the number of threads (PSMTID) is retained for non-clear resets and zero for clear resets. Process 500 returns to block 502.
When the load-normal, load-with-dump, load-clear, or load-clear-list-directed keys are activated. , CPU is loaded. When the channel command word (CCW) type initial program load operation completes successfully, the CPU transitions from the load state to the operating state.
A CPU reset can be used to clear the device check indicator and the resulting unpredictable elements of the CPU state with minimal information corruption. In particular, if you want to save the CPU state for operation analysis or resumption of operation, you can use CPU reset to clear the check status. If a CPU reset is performed by the load-normal key or the load-with-dump key, (a) the architecture mode can be set to the default mode, and (b) multithreading. Multithreading is disabled if the mechanism is installed and enabled. When the CPU reset sets the default mode, it allows you to save the current PSW so that you can restore it.
Initial CPU reset provides each function of CPU reset to the current PSW, CPU timer, clock comparator, and other registers: braking event address, captured PSW, control, floating point control, prefix and TOD. It is provided with the function of register initialization such as programmable registers. The initial CPU reset can set the architecture mode to the default mode when done by the load-normal key or the load-with-dump key. If multithreading is enabled when the initial CPU reset is done by invoking the load-normal key or the load-with-dump key, the lowest number of cores is assigned. The initial CPU reset function can be performed on the CPU, and the CPU reset is performed on all other CPUs in the core. A clear reset performs an initial CPU reset and a subsystem reset, as well as clearing or initializing all storage locations and registers on all CPUs in the configuration except the TOD clock. Clear does not affect external storage devices, such as direct access storage devices, that the control program uses to hold the contents of non-addressable pages.
A CPU power-on reset performs an initial CPU reset, clearing the contents of general purpose registers, access registers, control registers, and floating point registers and setting zero / default values with a valid checking-block code. Will be done. Note that clearing or initializing the state does not have to set the value to zero, and the value can be set to a non-zero value by default in the cleared state. If the configuration is set by a CPU power-on reset, it can set the architecture mode to the default mode. Otherwise, the architecture mode may be set to the mode of the CPU already in the configuration. CPU reset, initial CPU reset, subsystem reset and clear reset may be initiated manually.
In an exemplary embodiment, each CPU is assigned a number and is referred to as the CPU address. The CPU address uniquely identifies one CPU in the configuration. The CPU is specified by specifying this address in the CPU address field of the SIGP instruction. By storing this address in the CPU address field due to an interrupt, it is possible to identify the CPU that is issuing a malfunction alert, emergency signal, or external call. The CPU address is assigned by the configuration definition process and typically does not change as a result of the reconfiguration change. The program can determine the address of the CPU using the CPU address store instruction. The CPU address store instruction can also be used to specify a CPU address that identifies a CPU in a multithreaded configuration.
When multithreading is enabled, the CPU address can include core identification information (core ID) linked to CPU identification information within the core. The CPU identification information in the core is thread identification information (thread ID or TID). Within the configuration, all cores provide the same number of CPUs. However, depending on the model and CPU type, some CPUs in the core may not be in operation.
A fixed number of bits represent thread identification information based on the PSMTDID of the parameter register used by the signal processor multithreading order. This number of bits is called the TID width.
The core ID can be formed from the rightmost bit of the CPU address before enabling multithreading. The core ID is shifted to the left by the TID width bit, resulting in the leftmost bit of the CPU address after multithreading is available. Thread IDs have the same number of TID width bits and occupy the rightmost bit of the CPU address after multithreading is enabled. The thread ID can be assigned as a series of consecutive numbers. Table 1 exemplifies the relationship between PSMTID, TID width, and CPU address bits including core identification information and thread identification information.
<tables num="1"><img file="JP6509246B2_D0001.tif" /></tables>
FIG. 7 shows address extension as an example of CPU address extension processing 600A according to one embodiment. In block 602, the core address value 604 can be used as a few bits of CPU address bits to access the primary thread in ST mode. Arrow 606 indicates switching from ST mode to MT mode. At block 608, the extended address value 610 can be used to access the primary thread or one or more secondary threads in MT mode. Extended address value 610 includes core address value 604, shifted as shift core address value 612 and concatenated with thread address value 614. The shift core address value 612 is the core identifier (core ID) and the thread address value 614 is the thread identifier (TID). The shift core address value 612 can be shifted by an amount based on the requested maximum identifier, eg PSMTID. The few bits of the TID bit in the thread address value 614 can be determined based on the PSMTID as shown in Table 1 above. The thread address value 614 can be concatenated to the lower bits of the shift core address value 612 to form the extended address value 610. An all-zero thread address value of 614 specifies the primary thread, and values greater than zero identify and address the secondary thread.
When switching between MT mode and ST mode, select the core address value 604 (ST mode) or the extended address value 610 (MT mode) and use it as the CPU address in ST mode or MT mode, respectively. The core address value 604 is an example of a standard format address used in ST mode, where the core returns from MT mode to ST mode based on disabling MT mode. In one embodiment of the example, only the primary thread is accessible (ie, the secondary thread is inaccessible) based on the disabling of MT mode. FIG. 8 shows an example of the CPU address reduction process 600B according to the embodiment. Arrow 616 in FIG. 8 indicates switching from the MT mode of block 608 to the ST mode of block 602. To return from MT mode to ST mode, shift the extended address value 610 to the right, delete the thread address value 614, and change the core address value 604 (core ID) from the shift core address value 612. It can include forming a standard format address to include as a CPU address.
When multithreading is disabled by the reset function, (a) the CPU address of the CPU with thread ID zero is shifted to the right by the same number of bits as the TID width bits used for activation, and (b) the address Zero is inserted in the number of TID width bits on the left side, and (c) the CPU address returns to the original non-multithreaded format (ie, standard format address). When multithreading is disabled, all CPUs in the core that have a nonzero thread ID when multithreading is enabled are no longer operational.
If multithreading is not enabled, the CPU address does not change from the value assigned by the configuration definition process. In this case, the thread identification information does not exist.
Some signal processor instructions (order) are, for example, start, stop, resume, stop and state store, initial CPU reset, CPU reset, addressing state store, architecture settings, operational state sense, multithreading settings, addressing Instructions (orders) including additional state stores can be supplied to the CPU. An initial CPU reset or CPU reset can be initiated by a signal processor instruction, does not affect architecture mode or other CPUs, does not disable multithreading, and does not reset I / O.
The architecture order specifies the architecture mode in which all CPUs in the configuration are set to that mode. Architectural differences can include different addressing modes, register definitions, and instructions supported by the CPU. Changing the architecture mode allows the register bit selection field to be set to the default state (for example, zero), and the Access Register Translation Lookaside Buffer (ALB) and the Access Register Translation Lookaside Buffer (ALB) for all CPUs in the configuration. The translation lookaside buffer (TLB) is cleared and the ordering and checkpoint synchronization functions can be performed on all CPUs in the configuration.
The operating state sense instruction (order) can indicate whether or not the addressed CPU is operating. In ST mode, the indicator can be returned as a working / non-working state. In MT mode, a marker to identify if any of the CPUs in the core to which the addressed CPU belongs is running, or if all the CPUs in the core to which the addressed CPU belongs are not running. Can be used.
The MT mode setting instruction (order) enables the multithreading mechanism. The bit position of the parameter register can include the PSMTID given in the configuration. PSMTID can be defined by 1 less than the number of CPUs that can be addressed in each core. For example, a value of 3 at the specified bit position indicates that up to 4 threads will be served. The contents of the CPU address register of the SIGP instruction can be ignored because all CPUs in the configuration are considered to be addressed. If the MT setting instruction (order) is accepted, the MT setting instruction (order) is completed by all CPUs during the execution of the SIGP instruction. With reference to FIG. 9, the processing 700 of the SIGP MT setting instruction (order) 702 is illustrated. SIGP MT setting instruction (order) 702 with one or more of invalid orders, invalid states, and invalid parameters, as detailed herein with reference to process 700 in FIG. Is issued, an error indicator can be output to prevent the MT mode from being enabled.
If the multithreading mechanism is not installed in block 704, or if the CPU is not enabled in a valid architecture mode 708, the MT setting instruction (order) will not be accepted and will be invalid in block 706 or 710, respectively. order) The sign may be returned. If the other CPUs in the configuration are not stopped or checked in block 712, or if the configuration is already enabled for multithreading in block 716, the MT setting instruction (order) will not be accepted and block 714 respectively. Alternatively, a fraudulent status indicator may be returned at 718.
If PSMTID is invalid in block 720, the MT setting order may not be accepted and an invalid parameter indicator may be returned in block 722. When PSMTID is set to zero in block 724, the configuration is not enabled for multithreading, remains in ST mode, and outputs either state as a condition code in block 728. In one embodiment of the example, PSMTID is valid, non-zero, and the configuration is enabled for multithreading in block 726, resulting in CPU address extension for all CPUs in the configuration, ALB and TLB. The contents are cleared and the ordering and checkpoint synchronization functions are performed for all CPUs in the configuration. At block 728, the state can be output as a condition code. Upon successful completion, all CPUs except the CPU executing the MT setting instruction (order) remain in the stopped or checked stopped state. However, if the CPU was in a checked out state before multithreading was enabled, it may be unpredictable whether a CPU with a non-zero thread ID in the same core is in a stopped or unchecked state. ..
Thread contexts are also known as architected register contexts. Architected register context for each CPU before multithreading is enabled (ie PSW, CPU timers, clock comparators, general purpose registers, floating point registers and floating point control registers, vector registers, control registers, access. The contents of registers, prefix registers, and TOD programmable registers, etc.) become the architected register context of the CPU with TID zero for each core after multithreading is enabled. Similarly, an architect register context for a CPU with a TID of zero for each core in an MT-enabled configuration is the result of invoking the load-normal or load-with-dump keys. When multithreading is disabled, it becomes the architected register context for each CPU.
Architected register context for all CPUs with non-zero thread identification if the multithreading mechanism is disabled as a result of a load-normal or load-with-dump key operation. Can be held. If the multithreading mechanism is later re-enabled without the intervention of a clear reset, the architect register context of all CPUs with non-zero thread identification information is restored.
If multithreading is disabled by invoking the load-normal or load-with-dump keys and then re-enabled, the value of PSMTID in the bit of the parameter register will be The architect register context of all CPUs with non-zero thread IDs can be unpredictable if different from the one used in the previous enablement.
You can use the system information store instruction to store information about the components of a configuration in a system information block (SYSIB). SYSIB can include MT installed fields, MT generic fields, total CPU / core count, configured CPU / core count, standby CPU / core count, reserved CPU / core count, and other fields. The MT installed field can indicate whether or not the multithreading mechanism is installed and may also indicate the highest supported TID for the first core type, eg special core type. The MT generic field can indicate the highest supported TID for a second core type, eg generic core type. The highest supported TID in the MT generic field may be limited to less than or equal to the highest supported TID in the MT installed field. The total number of CPUs / cores can indicate the total number of general-purpose CPUs or cores including general-purpose CPUs in the configuration, regardless of whether they are in the configured state, the standby state, or the reserved state. The number of configured CPUs / cores can indicate the number of general-purpose CPUs or cores including general-purpose CPUs that are in the configured state, that is, in the configuration and ready to execute a program. The number of standby CPUs / cores indicates the number of general-purpose CPUs or cores including general-purpose CPUs that cannot be used for executing a program until the standby state, that is, the configured state. The reserved CPU / number of cores indicates the reserved state, that is, the number of general-purpose CPUs or cores including general-purpose CPUs that cannot be used for executing a program and cannot be made into a configured state.
FIG. 10 shows an example of storing multithreading function information according to one embodiment. Programs executed in threads such as thread 1 of core 800A are stored in the system information store (STORE SYSTEM INFORMATION) from memory 801 of configuration 850 such as LPAR. (STSI)) Instruction 830 can be fetched. As a result of executing the STSI instruction, the system information block (SYSIB) 802 is stored 832. In the example in Figure 10, SYSIB802 contains the MT installed identifier 804, which indicates whether configuration 850 supports multithreading. SYSIB802 also includes the maximum thread identifier of the highest supported threads for cores 800A / 800B, which can be given as the maximum TID806 per core for special cores and the maximum TID808 for generic cores. SYSIB802 can also include the current program-specified maximum thread identifier (PSMTID) 809. The current PSMTID809 reflects the multithreading mode when enabled programmatically within configuration 850. If the STSI instruction 830 is executed at the base machine level, the current PSMTID809 may not be defined.
A program running in a thread, such as thread 2 of core 800B, can also fetch the SERVICE CALL (SERVC) instruction 834 from memory 801 of configuration 850, in which case this instruction is system control program information. Read (read-system-control-program-information: Specify the read-SCP-info or RSCPI) command. By executing the RSCPI command, the service call control block (SCCB) 810 can be stored in the memory 801 836. In one embodiment of the example, the SCCB810 stored by executing the RSCPI command provides similar and additional information that may not be available in SYSIB802. In the example of Figure 10, SCCB810 contains the MT installed identifier 812, which indicates whether core 800B supports multithreading. The SCCB810 also includes the maximum thread identifier of the highest supported thread of core 800B, which can be given as the maximum TID814 per core for special cores and the maximum TID816 for general purpose cores. The values 812 to 816 of SCCB810 correspond to the values 804 to 808 accessible by SYSIB802. In addition, the SCCB810 can include a program-specified maximum thread identifier set at the end of the core 808B highest-supported thread, which is also referred to as the last-configured program-specified maximum thread identifier (PSMTID) 818. The SCCB810 can also include a mask of PSMTID values that can be accepted by the MT setting command (order) as the PSMTID support mask 820. The PSMTID support mask 820 can be used to identify supported CPUs / threads when a number less than the number defined by the maximum TID814 per core is desired.
It will be found that cores 800A and 800B also include other aspects not shown in this example. SYSIB802 and SCCB810 can also contain additional values not shown in the example in Figure 10.
FIG. 11 shows a process flow 900 for determining the multithreading function according to one embodiment. At block 902, the core executes a multithreading feature information retrieval (RMTCI) instruction. This instruction can be, for example, either a SERVC instruction or an STSI instruction. At block 904, get thread identification information that identifies the multithreading feature of the configuration. In block 906, the acquired thread identification information is stored. At block 908, it is determined whether the configuration was previously multithreaded enabled based on the thread identification information obtained.
As mentioned above, the SERVC instruction is configured to store the thread identification information in the in-memory response block (eg SCCB810 in Figure 10), and the STSI instruction stores the thread identification information in memory SYSIB (eg SYSIB802 in Figure 10). It is configured to store in. The acquired thread information can include an MT installed identifier (for example, MT installed identifier 804 or 812 in FIG. 10) indicating whether or not the core supports multithreading. The acquired thread information may also include the maximum thread identifier of the core's highest supported thread (eg, maximum TID value 806, 808, 814 or 816 in Figure 10). The acquired thread information can include the current program-specified maximum thread identifier (for example, the current PSMTID809 in FIG. 10) and the final setting program-specified maximum thread identifier (for example, PSMTID818 in FIG. 10). The response block can include a mask of bits indicating a particular thread identifier that is individually supported (eg, PSMTID support mask 820 in Figure 10). The determination of whether the configuration was previously MT-enabled can be based on the last-minute program-specified maximum thread identifier being a non-zero value (eg, last-minute PSMTID> 0). In one exemplary embodiment, the configuration supports multiple core types.
In one embodiment of the example, registers and values, such as program counter values, may be contained in the registers or managed separately and are captured as a thread context. Address extensions in MT mode make additional thread contexts accessible. As described above with reference to FIGS. 7 and 8, a CPU address is created for each core in the configuration. The CPU address can be looked up by the CPU address store instruction, shown in other structures, and used in various SIGP instructions (orders). If MT is not enabled, this addressing scheme will not change. When MT is enabled, the CPU address will be extended. As mentioned above, the non-MT enabled portion of the CPU address can be shifted to the left by enough bits to accommodate the TID. For example, SIGP where the operating system specified a PSMTID value of 1. When the MT setting instruction (order) is issued, the CPU address is shifted to the left by 1 bit. If the PSMTID is 2 or 3, the CPU address will be shifted to the left by 2 bits. If the PSMTID is 4 to 7, the CPU address will be shifted to the left by 3 bits, and so on.
If multithreading is later disabled (as a result of a clear reset or CPU reset performed by a load-normal operation), CPU address reduction will occur. MT enabled CPU address, MT enabled SIGP It can be shifted to the right by the same number of bits as the number of PSMTID bits used in the MT setting instruction (order), and the thread ID part of the address disappears. Thread contexts accessible in MT mode can reside in one or more storage locations, as in the example shown in Figure 12. In the example of FIG. 12, configuration 1000 may include core 1002 and further cores (not shown). Memory 1006 can include configuration memory 1005 as part of configuration 1000 and can include host / firmware memory 1007 separate from configuration 1000. The host / firmware memory 1007 can include a state description block 1008 maintained by the host, which can store the thread context 1010 of a thread (eg, thread n in FIG. 12). Satellite block 1012 can be anchored to state description block 1008 in memory 1006 as part of host / firmware memory 1007, in which case satellite block 1012 can replace thread context 1010 or It can include thread context 1014 in combination with thread context 1010. Each thread can have a corresponding state description block 1008 and optionally a satellite block 1012, in which the thread context 1010 or the thread context 1014 can be stored. In yet another alternative, the hardware context register 1016 can be used, for example to store the thread context 1018 in core 1002. These examples of thread contexts 1010, 1014 and 1018 can be used in combination or separately as storage options. Regardless of whether the thread context is maintained or not, the thread context is directly activated when address shrinkage occurs.
When MT is disabled, CPU address reduction processing makes core threads 1 to n unaddressable. Similarly, thread contexts containing architected registers are invisible to the program. If MT is disabled as a result of a CPU reset due to a non-clear load operation, the register context of threads 1 to n is retained. These data can be examined later when the configuration is returned to MT mode. As shown in Figure 12, the host sets the register context for each guest thread in state description block 1008 for that thread (or in satellite block 1012 anchored to the state description, as in the case of vector registers). Can be maintained.
Preserving the context of threads 1 to n while disabling MT is a diagnostic function that dumps the thread status after an OS failure occurs. After an OS failure, the operator can choose to run a stand-alone dump (SADMP) program to capture the system's memory and thread context at the time of the failure. However, loading the SADMP program may revert the configuration to the default architecture mode with ST mode enabled, thus disabling MT. However, since SADMP is loaded by a non-clear load operation, the register context of threads 1 to n of each core is retained. SADMP can determine if MT was enabled in the dumped configuration by examining the results of the response block of the SERVC SCP information read command. This number can then be used as an input to the SIGP MT order to re-enable MT at the same level as before.
FIG. 13 shows an example of multithreading register storage according to one embodiment. A system such as the computer system 1100 of FIG. 13 may include multiple configurations 1102 and 1104. In the example of FIG. 13, configuration 1102 includes cores 1106 and 1108, and configuration 1104 includes cores 1110 and 1112. Configurations 1102 and 1104 can be independently switched between ST mode and MT mode at different times. Configurations 1102 and 1104 of computer system 1100 can be configured with different numbers of maximum thread IDs to support different numbers of threads enabled simultaneously in configurations 1102 and 1104, respectively. In the example of Figure 13, cores 1106 and 1108 each support up to two threads while configuration 1102 is in MT mode 1114, whereas cores 1110 and 1112 are while configuration 1104 is in MT mode 1116. Each supports up to 4 threads.
While MT mode 1114 is enabled in configuration 1102, both TID0 and TID1 are accessible as separate thread contexts, such as separate instances of thread context 1115. At point 1118, MT mode 1114 can be disabled by a load-normal operation or non-clear reset to configuration 1102, which switches both cores 1106 and 1108 to ST mode 1120. The TID0 register is accessible in ST mode 1120 due to address reduction as described above. However, the TID1 register, which was accessible in MT mode 1114, is retained but not accessible. For example, the TID1 register may be implemented as thread context 1010, 1014 or 1018 in FIG. 12, in which case the address available by address extension will be after address reduction when switching to ST mode 1120. It is no longer accessible.
Configuration 1104, while MT mode 1116 is enabled, in the TID0, TID1, TID2, and TID3 registers as separate thread contexts, such as separate instances 1010, 1014, or 1018 of the thread context in Figure 12. It is accessible. In this example, TID0 represents the primary thread and TID1 through TID3 represent the secondary threads that are maintained separately for cores 1110 and 1112, respectively. At point 1122, a clear reset to configuration 1104 can disable MT mode 1116, which switches both cores 1110 and 1112 to ST mode 1124. A clear reset at point 1122 can clear all of the TID0, TID1, TID2, and TID3 registers. Due to the address reduction described above, the TID0 register is accessible in ST mode 1124. However, the TID1, TID2, and TID3 registers that were accessible in MT mode 1116 are retained in a cleared state but are no longer accessible. As shown in FIG. 13, with the action localized to each configuration 1102 and 1104, the operation can be performed independently on each configuration 1102 and 1104 at different time points 1118 and 1122. Thus, configuration 1102 can be in ST mode 1120, while configuration 1104 can be in MT mode 1116, and ST / MT mode does not have to match for all configurations in computer system 1100.
FIG. 14 shows a processing flow 1200 of multithreading register storage according to one embodiment. At block 1202, switching from MT mode to ST mode is performed based on the judgment by the core of MT mode that MT is invalidated in the core. The primary thread in MT mode can be maintained as the only thread in ST mode. Prevents application programs from accessing one or more thread contexts that contain program-accessible register values and program counter values for secondary threads. At block 1204, based on this switch, the operation type (eg, clear or non-clear) is to clear the program accessible register value or to hold the program accessible register value. Judged. At block 1206, it is determined to hold the program accessible register value based on the non-clearing operation. At block 1208, a decision is made to clear the program accessible register based on the clear operation.
As mentioned above, the program accessible register and program counter values in the thread context can include program general purpose registers, floating point registers, control registers, access registers, prefix registers, and TOD programmable registers. it can. Control registers can include floating point control registers, runtime-instrumentation control, CPU measurement control, and so on. Other examples of registers that can be contained in a thread context include program state words (eg, program counters / instruction addresses, condition codes, and other information for controlling instruction ordering and determining CPU state. Includes), vector registers, CPU timers, clock comparators, braking event address registers, and other registers well known in the art. As mentioned above, the PSMTID is set based on the last successfully executed signal processor instruction with MT enabled. Based on the switch to MT mode, the program accessible register value is made accessible to the application program based on the corresponding secondary thread being reenabled. For example, by returning from ST mode 1120 to MT mode 1114 in FIG. 13, the TID1 register becomes accessible and TID1 can be re-enabled. The thread context can be maintained by either a state description block, a satellite block anchored to a state description block in memory, or a context register such as thread context 1010, 1014, or 1018 in Figure 12.
The primary thread context can include the program accessible register and program counter values of the primary thread, such as the TID0 and TID0 registers of configuration 1104 in Figure 13, in which case the application program is in the primary thread context. Can be accessed in both ST mode 1124 and MT mode 1116. The secondary thread context can include program accessible register values and program counter values of the secondary thread, such as the TID1 to TID3 and TID1 to TID3 registers of configuration 1104 in FIG.
FIG. 15 shows an example of multithreading register restoration according to one embodiment. The example in Figure 15 includes a computer system 1300 with a single configuration 1302. Configuration 1302 includes core 1304, core 1306, and core 1308. Cores 1304 to 1308 each contain up to four threads (TID0, TID1, TID2 and TID3) in this example. In MT mode 1310, all thread contexts of TID0 to TID3 are available in cores 1304 to 1308. At time point 1312, MT mode 1310 can be disabled by normal load operation or non-clear reset of configuration 1302 that switches cores 1304 to 1308 to ST mode 1314. In ST mode 1314, the TID0 registers remain accessible and the TID1 to TID3 registers are inaccessible but retained for each of cores 1304 to 1308. At point 1316, SIGP to enter MT mode MT can be re-enabled by executing the MT setting instruction (order). In the resumed MT mode 1318, access to the thread context of the respective TID1 to TID3 registers on cores 1304 to 1308 is restored. This allows a dump program, such as standalone dump program 1320, to inspect all threads' registers, including the TID1 to TID3 registers, to save thread context information for analysis.
Figure 16 shows that a stand-alone dump program, such as the Standalone Dump (SADMP) program 1320 in Figure 15, can be used to capture the thread's Architected Register context after an operating system failure. The flow 1400 of the multithreading register restoration processing according to an embodiment is shown. At block 1405, a non-clear load operation (eg, normal load or dumped load) loads the SADMP program. The non-clear load operation implicitly returns the configuration to ST mode, such as ST mode 1314 in configuration 1302 in Figure 15. Then, at block 1410, the SADMP program can use the STSI or SERVC instructions to query whether the MT mechanism is available in the configuration. If MT is installed, the SADMP program queries block 1415 for the last-minute program-specified maximum thread identification information (PSMTID) configured for this configuration. If MT has never been set for this configuration, the last-minute PSMTID value will be zero. Then, at block 1420, the SADMP program can execute an instruction to re-enable multithreading regardless of the value of the last-minute PSMTID. If the query in block 1410 reveals that MT is not installed, no attempt is made to query the last-minute PSMTID value in block 1415 or re-enable MT in block 1420.
The SADMP program attempts to call each CPU (thread) to save the architect register context of each other CPU (thread) in the configuration to a predefined storage location in memory. If MT was not pre-enabled before loading SADMP, the CPU address is in normal non-extended form. If MT was pre-enabled, the CPU address is an extended form that includes a core ID and a thread ID. At block 1425, SADMP starts at CPU address (N) zero, and at block 1430, it is determined whether the CPU address indicates the CPU on which SADMP is running. If it indicates a CPU running SADMP, that CPU / thread is skipped and N is incremented to the next value in block 1450. If N is different from the current CPU address, in block 1435, for example, the SIGP store-status-at-address instruction (SIGP store-status-at-address) instruction (SIGP stop and status store (SIGP)). Execution of the stop-and-store-status instruction (order) signals the CPU / thread to store its architected register context in memory. If the configuration has vector functionality, the SIGP address added state store (SIGP) to store the contents of the CPU / thread vector registers. The store-additional-status-at-address) command can also be executed. At block 1440, it is determined whether the signal at block 1435 was successful. If successful, at block 1445, the SADMP program saves its CPU / thread's register context to a dump file on tape or disk. If the signal of block 1435 is unsuccessful (for example, if the thread is not in operation) at the judgment of block 1440, the CPU / thread is skipped, N is incremented at block 1450, and processing continues. At block 1450, the value (N) of the CPU address used for signal transmission is incremented, and at block 1455 it is determined whether N is greater than the highest possible CPU address in the configuration. If N is not greater than the highest possible CPU address in the configuration, block 1430 determines if N indicates the current CPU / thread that the SADMP program is running and continues processing. If N is greater than the highest possible CPU address in the configuration, block 1460 has completed the Architected Register context restore and dump.
Although only one core of the configuration is described in FIG. 16, the processing flow 1400 of FIG. 16 can be expanded to execute for the maximum CPU address across all cores of the configuration including multiple cores. You will see that. Additional tweaks can be made in the configuration to support dumping for OSs that do not support MT or programs that recognize MT but do not use MT. For example, a clear reset can be performed before loading an OS that does not support MT in the configuration to prevent the MT-aware standalone dump program from attempting to dump secondary threads from the configuration. As another example, a program that recognizes MT but does not utilize MT may issue an MT order with the corresponding maximum thread ID of zero before running a standalone dump program on the configuration. it can.
Technical benefits and benefits include thread context restoration in multithreaded computer systems that support both single-threaded and multithreaded operating modes. The thread context used during multithreading mode can be saved, but remains inaccessible in singlethreaded mode, for example, when a standalone dump program provides diagnostic information about a software or hardware failure. The thread context can be restored when multithreading mode is resumed for use in collection.
The systems described herein allow software to mitigate hardware variability by explicitly requiring the OS to "choose" to use MT hardware. When the OS understands the MT characteristics of the execution environment, the OS has the ability to explicitly manage the thread density per core (as long as there is a workload dispatch pattern). The OS can choose to maintain high thread density even when computational resources are low, thereby reducing much of the total computing power variability found in other MT implementations. As a direct result of maintaining high thread density, both transaction response time and billing surface variability can be reduced.
Embodiments include systems, methods and computer program products for thread context restoration in multithreaded computer systems. One aspect is a configuration that includes a core that can be switched between single-threaded (ST) mode and multithreaded (MT) mode. ST mode handles the primary thread, and MT mode handles the primary thread and one or more secondary threads on the shared resource of the core. A multithreading mechanism is configured to control the utilization of the configuration and perform methods that include disabling one or more secondary threads based on switching from MT mode to ST mode. Prevents a program from being used in a thread context that contains program-accessible register values and program counter values for one or more secondary threads. Inquire about the maximum MT level specified immediately before in ST mode in order to determine the maximum thread id specified by the program specified immediately before the configuration. Based on the fact that the maximum thread id specified by the last-minute setting program indicates MT, a) the MT setting instruction (instruction) is executed to restart MT mode, and b) the restarted MT mode is set. Gets the thread context of one or more secondary threads by accessing and executing accessing the thread context of one or more secondary threads based on.
According to another aspect, a computer implementation method for restoring the thread context in the configuration is provided. The configuration includes cores that can be switched between single-threaded (ST) mode and multithreaded (MT) mode, ST mode handles the primary thread, and MT mode handles the primary thread and 1 on the core's shared resources. Handle with one or more secondary threads. This method involves disabling one or more secondary threads based on switching from MT mode to ST mode. Prevents a program from using a thread context that contains program-accessible register values and program counter values for one or more secondary threads. Inquire about the maximum MT level specified immediately before in ST mode in order to determine the maximum thread id specified by the program specified immediately before the configuration. Based on the fact that the maximum thread id specified by the last-minute setting program indicates MT mode, a) the MT setting instruction (instruction) is executed to restart MT mode, and b) the restarted MT mode is set. Based on this, you get the thread context of one or more secondary threads by accessing and executing the thread context of one or more secondary threads.
Yet another aspect includes a computer program product for restoring thread context in the configuration. The configuration includes cores that can be switched between single-threaded (ST) mode and multithreaded (MT) mode, ST mode handles the primary thread, and MT mode handles the primary thread and 1 on the core's shared resources. Handle with one or more secondary threads. This computer program product includes a computer-readable storage medium in which program instructions are embodied, and the computer-readable storage medium is not a signal. The program instruction can be read by the processing circuit to cause the processing circuit to execute the method. This method involves disabling one or more secondary threads based on switching from MT mode to ST mode. Prevents a program from being used in a thread context that contains program-accessible register values and program counter values for one or more secondary threads. Inquire about the maximum MT level specified immediately before in ST mode in order to determine the maximum thread id specified by the program specified immediately before the configuration. Based on the fact that the maximum thread id specified by the last-minute setting program indicates MT, a) the MT setting instruction (instruction) is executed to restart MT mode, and b) the restarted MT mode is set. Gets the thread context of one or more secondary threads by accessing and executing accessing the thread context of one or more secondary threads based on.
In addition to, or as an alternative to, one or more of the features described above, yet another embodiment includes an MT configuration instruction (instruction) including an MT configuration instruction (order) and a program-specified maximum thread id indicating MT. It can include forms that are signal processor instructions.
In addition to, or as an alternative to, one or more of the features described above, yet another embodiment comprises saving the thread context of one or more secondary threads based on switching to ST mode. be able to.
In addition to, or as an alternative to, one or more of the features described above, yet another embodiment is based on a non-clear reset operation when switching from MT mode to ST mode and MT to resume MT mode. Execution of instruction and access to the thread context of one or more secondary threads can include forms that are performed by a stand-alone dump program.
In addition to, or as an alternative to, one or more of the features described above, yet another embodiment is a stand-alone dump program immediately preceding program when issuing an MT order to resume MT mode. It can include a form in which the specified maximum thread id is specified as the program specified maximum thread id.
In addition to, or as an alternative to, one or more of the features described above, yet another embodiment MTs in the configuration to prevent the MT-aware stand-alone dump program from attempting to dump secondary threads from the configuration. Can include a form in which a clear reset is performed before loading an operating system that does not support.
In addition to, or as an alternative to, one or more of the features described above, yet another embodiment is a program that recognizes MT but does not utilize MT before running a stand-alone dump program for configuration. It can include a form that issues an MT setting instruction (order) with the corresponding maximum thread id zero.
In addition to, or as an alternative to, one or more of the features described above, yet another embodiment includes a form in which the last program specified maximum thread id is retained until a clear reset or deactivation of the configuration is performed. Can be done.
The terms used herein are for illustration purposes only and are not intended to limit the invention. Unless otherwise stated herein, the singular forms "a," "an," and "the" are intended to include the plural form as well. Also, as used herein, the term "comprises" and / or "comprising" may be any of the features, integers, steps, behaviors, elements, or components described. It specifies the existence of these combinations, but should be understood as not excluding the existence of one or more other features, integers, steps, behaviors, elements, components or groups thereof or combinations thereof. ..
Corresponding structures, materials, actions, and equivalents of all means or step plus functional elements in the appended claims perform their functions in combination with other specifically claimed elements. Intended to include any structure, material or action for. The description of the present invention is provided for purposes of illustration and illustration and is not intended to be exhaustive or limited to the present invention in the form of disclosure. Many changes and variations will be apparent to those skilled in the art without departing from the scope and gist of the present invention. The embodiments will be understood by those skilled in the art to best illustrate the principles and practical applications of the invention and for various embodiments with various modifications to suit the particular intended use. It has been selected and explained so that it can be done.
The description of the various embodiments of the invention is provided for illustrative purposes only and is not intended to be exhaustive or limited to the disclosed embodiments. Many changes and modifications will be apparent to those skilled in the art without departing from the scope and intent of the embodiments described. The terminology used herein is to best describe the principles of the invention, its practical application, or technical improvements in technology found on the market, or practices disclosed herein by one of ordinary skill in the art. It was chosen to allow the morphology to be understood.
FIG. 17 provides an overview of computer program product 1500 according to one embodiment, including computer readable storage medium 1502 and program instruction 1504.
The present invention can be a system, method or computer program product, or a combination thereof. The computer program product can include a computer-readable storage medium (or a plurality of computer-readable storage media) in which computer-readable program instructions for causing a processor to carry out an embodiment of the present invention are stored.
The computer-readable storage medium can be a tangible device capable of holding or storing instructions for use by the instruction execution device. The computer-readable storage medium can be, for example, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof, but is not limited thereto. A non-exhaustive list of more specific examples of computer-readable storage media includes: That is, portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM). Mechanical, such as portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD), memory sticks, floppy disks, punch cards or convex structures in grooves where instructions are recorded. There are devices encoded in, and any suitable combination thereof. Computer-readable storage media as used herein are radio waves or other freely propagating electromagnetic waves, waveguides or other transmission media propagating electromagnetic waves (eg, optical pulses through fiber optic cables), or electrical wires. It should not be interpreted as a temporary signal in itself, such as an electrical signal transmitted via.
The computer-readable program instructions described herein are each compute / from a computer-readable storage medium via a network such as the Internet, local area network, wide area network, or wireless network or a combination thereof. It can be downloaded to a processing device or to an external computer or external storage device. The network can include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, edge servers, or combinations thereof. A network adapter card or network interface in each computing / processing device receives computer-readable program instructions from the network and stores those computer-readable program instructions in a computer-readable storage medium in each computing / processing device. Transfer to do.
The computer-readable program instructions for performing the operations of the present invention are assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or Smalltalk (R). Source code or objects written in any combination of one or more programming languages, including object-oriented programming languages such as C ++ and traditional procedural programming languages such as the "C" programming language or similar programming languages. Can be code. Computer-readable program instructions are partly on the user's computer, partly on the user's computer, partly as a stand-alone software package, partly on the user's computer, partly on the remote computer, or in whole. It can run on a remote computer or remote server. In the latter case, the remote computer can connect to the user's computer over any type of network, including a local area network (LAN) or wide area network (WAN), or the connection is ( It may be done to an external computer (via the Internet, for example using an Internet service provider). In certain embodiments, an electronic circuit, including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), is a computer-readable program instruction to perform aspects of the invention. Computer-readable program instructions may be executed by personalizing the electronic circuit using the state information of.
Aspects of the invention are described herein with reference to flowcharts and / or block diagrams showing methods, devices (systems) and computer program products according to embodiments of the invention. It will be found that each block of the flow chart and / or block diagram, and the combination of the flow chart and / or block diagram, can be implemented by computer-readable program instructions.
These computer-readable program instructions form a means by which instructions executed through the processor of a computer or other programmable data processing device implement the functions / actions specified in the flowchart and / or block diagram. As such, it may be supplied to the processor of a general purpose computer, a dedicated computer, or other programmable data processing device to create a machine. These computer-readable program instructions are such that the computer-readable storage medium in which the instructions are stored includes a product containing instructions that implement the mode of function / action specified in the flowchart and / or block diagram. It may be stored on a computer-readable storage medium and instruct a computer, programmable data processing device, or other device, or a combination thereof, to function in a particular manner.
Computer-readable program instructions are such that instructions executed on a computer, other programmable device, or other device implement the functions / actions specified in the flow chart and / or block diagram. It may be loaded into another programmable data processing device, or other device, to perform a series of operating steps on a computer, other programmable device, or other device.
Flowcharts and block diagrams in the drawings show the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Note that each block in the flowchart or block diagram may represent a module, segment, or portion of an instruction that includes one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions described in the blocks may be performed in a reordered manner as described in the drawings. For example, two blocks shown in succession may actually be executed at substantially the same time, depending on the required function, or the blocks may be executed in reverse order in some cases. Good. In addition, each block of the block diagram and / or flowchart diagram, and the block diagram or flowchart diagram or a combination of both blocks perform the specified function or action, or a combination of dedicated hardware and computer instructions. Also note that it can be implemented by a dedicated hardware-based system that implements.
18 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13 Sheet 14 Sheet 15 Sheet 16 Sheet 17 Sheet 18
Every citation, both ways
| Document | Relation | Office |
|---|---|---|
| US20080114973A1 | Cites | United States of America |
| JP2007317171A | Cites | Japan |
30 members in 13 offices
Priority claims3
| Document | Office | Kind | Date |
|---|---|---|---|
| 14226911 | United States of America | – | |
| 201414226911 | United States of America | A | |
| 2015055444 | European Patent Office (EPO) | W |
Members30
| Document | Office | Kind | |
|---|---|---|---|
| CA2940988A1 | Canada | A1 | |
| US2015277920A1 | United States of America | A1 | |
| WO2015144477A1 | World Intellectual Property Organization (WIPO) | A1 | |
| US2015339121A1 | United States of America | A1 | |
| TW201610841A | Taiwan Province of China | A | |
| AU2015238663A1 | Australia | A1 | |
| US9417876B2 | United States of America | B2 | |
| SG11201606094TA | Singapore | A | |
| SG11201606094TA | Singapore | A | |
| US9454372B2 | United States of America | B2 | |
| KR20160113681A | Republic of Korea | A | |
| CN106133689A | China | A | |
| IL247887A0 | Israel | A0 | |
| IL247887D0 | Israel | D0 | |
| EP3123323A1 | European Patent Office (EPO) | A1 | |
| AU2015238663B2 | Australia | B2 | |
| JP2017513112A | Japan | A | |
| ZA201605466B | South Africa | B | |
| TWI614681B | Taiwan Province of China | B | |
| RU2016127444A | Russian Federation | A | |
| RU2016127444A | Russian Federation | A | |
| RU2016127444A3 | Russian Federation | A3 | |
| KR101868725B1 | Republic of Korea | B1 | |
| RU2670909C2 | Russian Federation | C2 | |
| RU2670909C9 | Russian Federation | C9 | |
| CN106133689B | China | B | |
| JP6509246B2This record | Japan | B2 | |
| IL247887A | Israel | A | |
| IL247887B | Israel | B | |
| CA2940988C | Canada | C |
10 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Decision of grant or rejection writtenTRDD | TRDD | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Report on retrievalJAPANESE INTERMEDIATE CODE: A971007A977 | A977 | |
| Written request for application examinationJAPANESE INTERMEDIATE CODE: A621A621 | A621 | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 |
Numbers
- Publication
- 6509246
- Application
- 2016557118
Titles2
- Japanese
- マルチスレッディング・コンピュータ・システムにおいてスレッド・コンテキストを復元するのためのコンピュータ・システム、コンピュータ実装方法およびコンピュータ・プログラム
- English
- Computer system, computer implementation method and computer program for restoring thread context in a multithreaded computer system
Classification
- CPC, 4
- G06F9/461
- G06F9/3851
- G06F9/30189
- G06F9/30145
- IPC, 3
- G06F9 46
- G06F9 48
- G06F9 30
