JP5328743B2 - Enhanced reliability of multi-core processors - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide the reliability strengthening of a multiple core processor. <P>SOLUTION: One embodiment includes a method for specifying an available core in the multiple core processor, allocating a core of a first subset to an enable state, allocating a core of a second subset to a standby state, and storing information about the allocations in a storage. In a specific embodiment, the core may be allocated to an enable state on the basis of temperature-aware algorithm. The other embodiments are described, and claimed. <P>COPYRIGHT: (C)2011,JPO&amp;INPIT

Description

  Embodiments described herein relate generally to a multiprocessor system, and more particularly, to improving the reliability of a multiprocessor system.

  Computer systems are becoming more complex and include advanced processors such as multi-core processors. A dual-core processor having two processor cores that execute instructions in parallel has been introduced. In the future, it is expected that a processor including more cores, for example, three or more cores will be produced. The current roadmap includes processors with 4 cores and 8 cores.

  Also, in the long term, processors are expected to evolve into a multi-core environment where there are many cores in a single processor package and many cores on a single substrate or die in the package. Is done. Therefore, it is expected that processors including 8, 16, 32, 64, 128, or more cores will be available in the future. In addition to the complexity associated with such multi-core processors, reliability concerns increase. Specifically, due to various technical challenges, the core of a multi-core processor will have a higher failure rate than a single core or dual core processor.

There are many causes for such a high failure rate, and when all of these causes are combined, the cores of a multi-core processor may have a reduced lifetime for each generation. The cause of such a reduction in life is required for many deterioration sources such as electromigration, stress migration, dielectric breakdown with time (TDDB), negative bias temperature instability (NBTI), and temperature cycling. Most of these failure mechanisms occur at high temperatures. That is, the higher the temperature, the shorter the core mean time to failure (MTTF). Usually, the core of the failure rate of the processor or processors, called the number of failures per hour (FIT), which is the number of faults to be expected in ¹⁰⁹ hours. Using the FIT value, MTTF can be calculated as 1 / FIT. The MTTF assuming steady state operation under fixed conditions (eg, temperature, voltage, frequency, and utilization) is calculated for a variety of techniques. Therefore, the lifetime reliability may be further deteriorated by increasing any of these parameters.

1 is a block diagram of a multi-core processor according to an embodiment of the present invention. FIG.

FIG. 3 is a flow diagram of a method according to an embodiment of the invention.

It is a flowchart of the core allocation method which concerns on one Embodiment of this invention.

It is a flowchart of the core reallocation method which concerns on one Embodiment of this invention.

It is a flowchart of the reliability maximization method which concerns on one Embodiment of this invention.

1 is a block diagram of a multiprocessor system according to an embodiment of the present invention.

  Embodiments of the present invention may be used to improve the reliability of semiconductor devices, particularly processors such as, for example, multiple core processors. In various embodiments, various schemes may be implemented that allocate the cores of a multi-core processor for instruction execution. In these allocation schemes, activated or enabled cores may be selected based on various operating parameters. The operating parameter considered when selecting the core to be activated is temperature in particular. Since many semiconductor failure mechanisms occur at high temperatures, temperature is directly related to the core MTTF and multiple core reliability. Thus, in embodiments of the present invention, a core granularity mechanism may be implemented to manage temperature to maximize multi-core reliability. While maximizing multi-core reliability, core degradation and processing variations may be further taken into account when assigning cores.

  In addition to the core allocation scheme, in embodiments of the present invention, reallocation may be performed, for example, when a currently enabled core fails or when processing at a desired operating level cannot continue. In various embodiments, as a consideration in the reassignment scheme, using temperature-based analysis to select one or more cores for use as active or enabled cores among the available spare cores Good. Furthermore, in the embodiment of the present invention, the core to be activated may be selected based on the processing load. For example, in order to improve the performance of processes that communicate with each other, closely related processes may be scheduled in cores having close relations to minimize the communication path.

  On multi-core processors, the core temperature can have a substantial side effect on adjacent cores. For example, if two adjacent cores are turned on simultaneously, their average temperature will be higher than if they are separated by one or more spare cores. The spare core (or the failed core) absorbs heat generated by the active core and lowers the temperature of the active core. As an example, consider a 32-core multi-core processor with 16 active cores and 16 spare cores. By using the allocation / reassignment scheme according to embodiments of the present invention, the core temperature can be significantly reduced. For example, a checkerboard pattern (eg, one online core and one spare core) can be operated at a lower temperature than when the activated cores are connected.

  The core reliability in a multi-core environment may be improved in this way to extend the life of the multi-core processor. Depending on the architecture desired, different embodiments may be implemented in different ways. In some embodiments, dedicated hardware may be used to select and control the cores of a multi-core processor. In other embodiments, software-only methods may be implemented. Of course, a predetermined amount of dedicated hardware may be used in combination with software that operates on the dedicated hardware and / or on other processing resources by modifying a hardware-only or software-only scheme. For example, in some embodiments, a microcontroller may be used to execute one or more algorithms implemented as controller microcode. In other embodiments, the algorithm may be implemented in software to execute on a dedicated core of a multi-core processor, or on a selected core or part thereof.

  The assignment / reassignment scheme may be on a per core (ie, core granularity) basis that minimizes core failure rates and thus maximizes multiple core reliability. In some embodiments, a substantial number of cores of a multi-core processor may be retained as reserves. When a core fails, a spare core may be selected from the available spare pool and may be selected to maximize multi-core reliability.

  Most core failure mechanisms have a strong temperature dependence, and as a general rule the core failure rate increases at higher temperatures. Therefore, the reliability of multi-core processors will be expanded by a core allocation / reassignment scheme that takes temperature into account. In some embodiments, a multiple core usage model can be implemented that maximizes the persistence of the performance level that guarantees the target lifetime. Similarly, the model can maximize the lifetime so that the targeted performance level is guaranteed. In these models, which provide initial core allocation and core reconfiguration in case of core failure or when the system is unable to provide the desired performance, processing variations and frequency aging are taken into account. Further, in some embodiments related to applications where different cores communicate, performance may be balanced with reliability.

  FIG. 1 is a block diagram of a multi-core processor according to an embodiment of the present invention. As shown in FIG. 1, the processor 10 includes a plurality of individual cores 15. More specifically, the embodiment of FIG. 1 illustrates a configuration that includes an array of 8 × 8 cores that are coupled through interconnect fabric 30. While showing this specific example according to the embodiment of FIG. 1, the scope of the present invention is not limited thereto, and in other embodiments other configurations, such as a one-dimensional, two-dimensional, or three-dimensional mesh It will be appreciated that a one-dimensional, two-dimensional, or three-dimensional torus configuration may be used. In addition, although the embodiment of FIG. 1 illustrates 64 individual cores, it will be appreciated that in other embodiments a multiple core processor may include more or fewer cores.

  Each core 15 is relatively small compared to at least a single core or dual core processor. In various embodiments, each core 15 may include local memory (eg, cache memory) and may be further connected to shared memory. Specifically, as shown in FIG. 1, a shared memory 20 that is a global shared memory may be connected to the individual core 15 via the interconnect fabric 30. Although not shown in FIG. 1 for ease of illustration, it will be appreciated that the processor 10 may include other components, such as input / output (I / O) interfaces, interconnects, buses, logic, and the like.

  The core 15 to be activated may be selected based on various algorithms. In order to enable such activation, the interconnect fabric 30 may be configured to improve the connection between the activated cores 15 and increase the communication speed.

  FIG. 2 is a flow diagram of a method according to an embodiment of the invention. As shown in FIG. 2, method 100 may be used to assign cores of a multi-core processor so that a desired level of performance is achieved. In various embodiments, the method 100 may be performed, for example, in a dedicated microcontroller, other logic, or processor core. As shown in FIG. 2, method 100 may begin by identifying available cores of a multi-core processor (block 110). For example, at initialization or at other occasions, a poll request may be sent to all cores and a response from a respondable core (ie, a core that has not failed) may be received.

  With continued reference to FIG. 2, a first group of cores in the processor may then be assigned an active status (block 120). In some embodiments, cores may be assigned to the first group based on the relative position of the cores relative to other active cores. That is, in various embodiments, the analysis of cores to be enabled may take into account the status of adjacent cores. Since the temperature of the active core is dissipated through the failed core or the spare core adjacent to the active core, it is possible to obtain a low operating temperature by selecting the core having the smallest number of active adjacent cores as an enable target. You can do it. Cores may be assigned to the first group until a given performance level is reached. Performance levels are variously represented, for example, by the number of instructions per second or other similar indicator. Based on the first group of cores 15 (shown in FIG. 1) that are activated to operate, the interconnect fabric that connects the cores may be configured or reconfigured. More specifically, the interconnect fabric may be selectively controlled so that communication between the cores of the first group is improved. In one embodiment, the switches that make up the interconnect fabric may be configured such that the first group of cores are efficiently connected.

  With continued reference to FIG. 2, a second group of cores may then be assigned to a spare status (block 130). That is, when the desired level of performance is reached by enabling some cores into the first group, the remaining available cores may be put into the second group in the spare status. As will be described later, these spare cores can later be transferred from the second group to the first group.

  With continued reference to FIG. 2, the multi-core processor may proceed to normal operation after the available cores are assigned to the first and second groups, for example at initialization. During this operation, it may be determined whether a core failure has occurred (diamond 140) at a given interval of polling operation or a given interval of receiving a signal. If a failure occurs, control returns to block 110 described above. Therefore, the above flow may be executed again to reassign one or more cores as a replacement for the failed core.

  With continued reference to FIG. 2, if it is determined that there is no core failure in diamond 140, control proceeds to diamond 150. In diamond 150, it may be determined whether a change in performance level has occurred. Two types of performance level changes can occur. One is a change in the case where the user is instructed to change the desired performance level. For example, the user may desire higher performance to perform more complex operations. The second type of performance change is when, for example, the actual performance level of a multi-core processor changes due to one or more cores not operating at the previous frequency. Thus, if such a performance level change is determined at diamond 150, control returns to block 110 to reassign one or more cores. If such a performance level change is not determined in diamond 150, control returns to diamond 140 described above. While this particular example has been described in the embodiment of FIG. 2, it will be understood that the scope of the invention is not limited thereto.

  Although the method of FIG. 2 illustrates a general procedure for core assignment and reassignment, in some embodiments, different algorithms may be implemented for core assignment and reassignment. In some embodiments, similar active core selection may be performed in both schemes, for example using a greedy optimization approach. However, in other embodiments, different core selection methods may be implemented in the allocation scheme and the reallocation scheme.

  FIG. 3 is a flow diagram of a core allocation scheme according to an embodiment of the present invention. As shown in FIG. 3, the method 200 may begin with receiving core status information (block 210). For example, when a multi-core processor has a higher output, each core may send a signal indicating that the higher output is successful and available and the current maximum operating frequency. Next, at block 220, all healthy cores may be initialized as spares (block 220). Therefore, a preliminary list in which the number of healthy cores existing in a multi-core processor is initially input is maintained.

  Next, it may be determined whether the current performance is below the target performance level (diamond 230). The performance level may correspond to the number of healthy cores desired for operation, the number of instructions per second, or another similar metric. If it is determined that the performance level is not below the target level, the method 200 may end. Otherwise, control proceeds from diamond 230 to block 240. At block 240, cores may be assigned based on a reliability maximization algorithm as described herein (block 240). Note that after this assignment, the interconnect fabric that connects the cores may be configured according to the assignment. That is, the core may be activated based on an algorithm aimed at maximizing the reliability of the multi-core processor. Various methods for maximizing multi-core reliability may be implemented. However, in many embodiments, cores may be allocated in a manner that aims to reduce the overall temperature of a multi-core processor or to reduce the operating temperature of at least one active core of a multi-core processor. . As described below, specific examples of such reliability maximization algorithms may be performed by various embodiments.

  With continued reference to FIG. 3, control proceeds from block 240 to block 250. In block 250, the selected core may be identified as active. For example, in one embodiment, the core location map implemented by a bitmap or other storage form is provided with an entry corresponding to the activated core, i.e., the core set to the active state, to activate the core. It may be possible to identify that there is. Control then proceeds to block 260. In block 260, the reserve core count value may be decremented (block 260). As shown in FIG. 3, control returns from block 260 to diamond 230 described above.

  Although this particular example has been described in the embodiment of FIG. 3, it will be appreciated that the scope of the present invention is not so limited and other methods of core allocation may be implemented. In some embodiments, the method 200 of FIG. 3 may be performed each time a multi-core processor is powered up. However, the method 200 may be implemented at various other occasions, such as at processor reset or other similar event.

  FIG. 4 is a flowchart of a reallocation method according to an embodiment of the present invention. Similar to the method 200 described with respect to FIG. 3, the method 300 of FIG. 4 may be performed via a microcontroller, dedicated logic, a core of a multi-core processor, or other means.

  As shown in FIG. 4, the method 300 may begin with receiving core failure information (block 310). For example, a core that is about to fail may send a failure signal. Alternatively, the core may be polled periodically by a polling method, for example according to a watchdog timer mechanism. If the core does not respond to polling, it indicates a failure. Upon receiving such failure information, the failed core may be identified as a failed core (block 320). For example, a core map such as a bitmap may be updated with failure information.

  Control may then proceed to diamond 330. In diamond 330, it may be determined whether the performance of the multi-core processor is below a target level (in light of the failure) (diamond 330). If not, method 300 may end. If so, control proceeds from diamond 330 to block 340. In block 340, cores may be allocated based on a reliability maximization algorithm (block 340). The interconnect fabric may also be reconfigured accordingly. Control proceeds from block 340 to block 350. In block 350, the selected core may be identified as active. Control may then proceed to block 360 and decrement the reserve core count value (block 360). As shown in FIG. 4, control returns from block 360 to diamond 330 described above.

  As described above, regardless of whether the mode is the allocation mode or the reallocation mode, in the embodiment, the reliability maximization algorithm may be implemented in selecting a core to be activated. FIG. 5 is a flowchart of a reliability maximization method according to an embodiment of the present invention. As shown in FIG. 5, the method 400 may begin, for example, by selecting a spare core in the spare core list for analysis (block 410). The analysis may begin by identifying cores that are adjacent to the core to be analyzed (block 420). In some embodiments, one to four cores are adjacent to a given core, depending on the given processor arrangement and the location of the given core. Accordingly, in block 420, these adjacent cores may be identified. Next, the number of adjacent cores in a failed or spare state is determined (block 430).

  Control proceeds from block 430 to diamond 440. In diamond 440, it may be determined whether the number determined in block 430 for the selected core (ie, the number adjacent) is greater than the number for the current optimal core (diamond 440). That is, the current number of neighbors may be compared to the value of the previously analyzed core that has the largest number (adjacent spare or failed cores). If the number of selected cores is greater, control proceeds to block 450 where the selected core is set as the optimal core. Control proceeds from block 450 or diamond 440 to diamond 460. In diamond 460, it may be determined whether a spare core that has not been analyzed remains (diamond 460). If so, control returns to block 410 described above. If not, control proceeds to block 470. In control 470, the identified optimal core may be assigned (block 470). That is, the core with the smallest number of active adjacent cores is selected. In this manner, the failed adjacent core or the spare adjacent core helps to dissipate the selected active core, so that the temperature can be lowered in the selected core and in the entire multi-core processor. Although this particular example has been described in the embodiment of FIG. 5, it will be understood that the scope of the invention is not limited thereto.

  In some embodiments, an algorithm may select which core to activate to maximize multi-core reliability and ensure target performance. The microcontroller may collect information globally about which core has failed and which core is currently connected or in a spare state. In one embodiment, this information may be maintained as a bitmap on the microcontroller. In another embodiment, a failure may be expressed as a complete failure of the core or a decrease in operating frequency but the core will continue to operate. Cores degraded due to aging effects that raise the threshold voltage of p-channel metal oxide semiconductor (PMOS) transistors over time, such as oxide thickness problems, NBTI effects, etc., cannot operate at the original frequency, but at lower frequencies Can work.

  When assigning / reassigning cores, the core bitmap on the microcontroller may be updated. In another embodiment, the algorithm may be implemented as software and executed on the core as a kernel or user process. Alternatively, the algorithm may be implemented as hardware (eg, a simple embedded core / ROM combination) and be part of a microcontroller. In either case, the algorithm is executed relatively infrequently (eg, when a core fails or when a substantial change in load occurs), so the mechanism-dependent output impact is minimal. It is the limit.

  In one embodiment, the algorithm maximizes multi-core reliability in the event of a core failure, with an initial core assignment section that selects which core should be online (ie, active or enabled) It has two sections with a reconfiguration section that determines which spare cores to activate. The algorithm may further handle communication processing (eg, in the reconfiguration section) and assign them to the cores so that performance is maximized.

  Table 1 shows a pseudo code notation of an algorithm according to an embodiment of the present invention.

  As shown in Table 1, in the allocation part (CORE ALLOCATION), cores may be selected until a preset performance target is reached. The performance goal may correspond to the number of cores available to the user (eg, based on the average selling price of the processor). Alternatively, the performance goal may be an abstraction of the total computing power of a multi-core processor, allowing for processing variations and core degradation to be taken into account. Due to these challenges, some cores may be slower than others. In such embodiments, the core speed may be reported to the microcontroller via an in-die variation probe (IDVP) per core. The speed of each core may be stored by the microcontroller as a consideration in the core assignment loop.

  Still referring to Table 1, the reconfiguration part (CORE RECONFIGURATION) is activated due to a core failure. One (or more) spare cores may be connected until the target performance is reached. In the reassignment, a decrease in the core frequency may be considered. When core IDVP or predictable core mileage monitoring circuits report a decrease in core frequency to the microcontroller, the core speed is updated in the microcontroller memory and degradation is taken into account in the core reconfiguration loop Is done. When the current performance falls below the target performance due to deterioration, the core is further connected.

  As shown in the embodiment of Table 1, both the core allocation section and the core reassignment section use the same function T-aware_cores, that is, a temperature-aware function that selects a spare core to be connected. The function T-aware_cores uses a greedy optimization approach that selects the optimal spare core from the available spare set to maximize multi-core reliability. In the embodiment of Table 1, the optimal core is the core with the fewest connected adjacent cores. It should be noted that the failed core is also considered when checking the adjacent core of the candidate core, since the failed core has similar heat dissipation characteristics as the spare core. It should also be noted that cores that fail due to yield issues (if any) are considered neighbors of the candidate core, thus expanding the optimization opportunities that increase the reliability of the working core. .

  As a secondary consideration, inter-core communication can be considered from a performance perspective. Therefore, if there is communication between processes, an optional secondary optimization path is activated after selecting a core to be connected. In some embodiments, an operating system (OS) may provide this data to the microcontroller. This optimization path (i.e., function Minimize_communication in Table 1) can improve performance by assigning processes that communicate with each other to adjacent cores using an aggressive optimization approach. Starting from the connected core, this path assigns the next intercommunication process to the closest core. This assignment may be repeated until all of the desired cores are online. In other embodiments, the temperature aware algorithm may be disabled and multiple cores in close proximity to each other may be assigned to processes that are in close communication with each other, eg, processes that are closely related.

  That is, the allocation / reassignment mechanism according to the embodiment of the present invention can be enabled and disabled via OS / application control. For example, if the ratio of the amount of traffic to the amount of computation is high, these mechanisms may be disabled to make reliability a secondary target, and cores close to each other may be assigned to improve performance. . However, in other embodiments, the mechanism may be enabled during this period, as the core failure rate will increase during the majority of the wear-out period of the multi-core processor lifetime.

  Embodiments may be implemented in many different system types. FIG. 6 is a block diagram of the multiprocessor system according to the embodiment of the present invention. As shown in FIG. 6, the multiprocessor system is a point-to-point interconnect system and includes a first processor 570 and a second processor 580 coupled via a point-to-point interconnect 550. However, in other embodiments, the multiprocessor system may be of another bus architecture, such as a multi-drop bus or another such implementation. As shown in FIG. 6, each of processors 570 and 580 may be a multi-core processor including first and second processor cores (ie, processor cores 574a and 574b, and processor cores 584a and 584b), There may be other cores in certain embodiments, possibly more other cores. Processors 570 and 580 may further include controllers 575 and 585, respectively, that function as allocators that perform core assignments for multi-core processors. In various embodiments, the controllers 575 and 585 may be microcontrollers programmed according to an embedded ROM that includes an assignment program and may assign cores to groups based on a temperature-aware algorithm, but other implementations. Examples are also possible. Although not shown in detail in the embodiment of FIG. 6, controllers 575 and 585 are bitmaps that identify the cores present in processors 570 and 580 and the status of each of those cores (eg, active, spare, or failed). Alternatively, a memory for storing other map information may be included.

  With continued reference to FIG. 6, the first processor 570 further includes a memory controller hub (MCH) 572 and point-to-point (PP) interfaces 576 and 578. Similarly, the second processor 580 includes an MCH 582 and PP interfaces 586 and 588. As shown in FIG. 6, MCHs 572 and 582 connect the processor to memory, ie, memory 532 and memory 534, respectively, which may be part of the main memory locally attached to each processor. In some embodiments, at least some capacity of global memory may be implemented within processors 570 and 580.

  In some embodiments, the operating system (OS) of the multiprocessor system may run on one or more of the first processor 570 and the second processor 580. The OS may include a scheduler that schedules processing on these processors and their cores. In some embodiments, controllers 575 and 585 may provide map information including identification of active, spare, and failed cores. The scheduler may use this information to route processing to or from one or the other of the first processor 570 and the second processor 580 or between the cores that they have. Further, the scheduler may perform other control functions based on the assigned cores, for example, core assignments that reduce the distance between processes that communicate with each other. In other embodiments, such scheduling may be performed by controllers 575 and 585 or at other locations in processors 570 and 580.

  The first processor 570 and the second processor 580 may be connected to the chipset 590 via PP interconnects 552 and 554, respectively. As shown in FIG. 6, the chipset 590 includes PP interfaces 594 and 598. The chipset 590 further includes an interface 592 that connects the chipset 590 to the high performance graphics engine 538. In one embodiment, the graphics engine 538 may be connected to the chipset 590 using an advanced graphics port (AGP) bus 539. The AGP bus 539 may be compliant with the Accelerated Graphics Port Interface Specification Revision 2.0 issued May 4, 1998 by Intel Corporation of Santa Clara, California. Alternatively, these components may be connected by a point-to-point interconnect 539.

  Next, the chipset 590 may be connected to the first bus 516 via the interface 596. In one embodiment, the first bus 516 may be a peripheral component interconnect (PCI) bus as defined in the PCI Local Bus Specification Real Machine Version Revision 2.1 dated June 1995, or a PCI Express bus. Or other third generation input / output (I / O) interconnect buses, but the scope of the invention is not limited thereto.

  As shown in FIG. 6, various I / O devices 514 may be connected to the first bus 516, and a bus bridge 518 that connects the first bus 516 to the second bus 520 may also be connected to the first bus 516. . In one embodiment, the second bus 520 may be a low pin count (LPC) bus. In one embodiment, various devices may be connected to the second bus 520, such as a data storage unit 528 including, for example, a keyboard / mouse 522, a communication device 526, and a code 530. Further, the audio I / O 524 may be connected to the second bus 520.

  Embodiments may be implemented with code and stored in a storage medium that stores the instructions that can be used to program execution of instructions into the system. Storage media include floppy disks, optical disks, compact disk read-only memory (CD-ROM), rewritable compact disks (CD-RW), all types of disks such as magneto-optical disks, read-only memory (ROM), dynamic random access Semiconductors such as random access memory (RAM) such as memory (DRAM) and static random access memory (SRAM), erasable programmable read only memory (EPROM), flash memory, electrically erasable programmable read only memory (EEPROM) It can be, but is not limited to, a device, a magnetic or optical card, or any other type of medium suitable for storing instructions in electronic form.

  Although the present invention has been described with respect to a limited number of embodiments, those skilled in the art will recognize numerous modifications and diversifications thereof. All such modifications and variations that come within the true spirit and scope of the invention are intended to be covered by the appended claims.

Claims (29)

The allocator identifies multiple available cores in a multi-core processor;
The allocator assigns a first subset of the plurality of available cores to an enabled state to perform processing and assigns a second subset of the plurality of available cores to a spare state;
The allocator stores information on the allocation in storage;
The allocator receives inter-core communication data from an operating system (OS);
Depending on the amount of inter-core communication data, the allocator may have a minimum number of cores adjacent to the core in the enabled state, or a plurality of cores close to each other for the process of closely communicating with each other. Assigning to the enabled state ,
A method comprising: The allocator further includes storing the information in a bitmap associated with the allocator, wherein the bitmap corresponds to an arrangement of cores of the multi-core processor, and the allocator includes the first and second allocators. Assign a subset of
The method of claim 1 . Said allocator, receives the failure information about the failed core of said first subset, the second subset of the core to claim 1 or 2 further comprising re-assigned as the core of the first subset The method described. The allocator further reallocating the cores of the second subset by identifying the cores of the second subset that are minimally adjacent to the cores included in the first subset; The method of claim 3 comprising. Based on the distance between the first core in the first subset and the second core in the first subset, the allocator assigns a first process to the first core and a second process Assigning to the second core, the first process and the second process communicate with each other;
The method according to any one of claims 1 to 4 . Via the core failed in the second of the many-core processor and the subset, the allocator, claim 1, wherein said first subset further includes dissipating heat generated in any one of the 5 The method described. The method of any one of claims 1 to 6 , further comprising the allocator assigning the first subset such that a reliability metric of the multi-core processor is maximized. The allocator further comprises disabling allocation of the first subset so that the reliability metric is maximized based on a ratio of traffic to computation in operation of the multi-core processor. 8. The method according to 7 . A multi-core processor including a plurality of cores located on the die and an allocator that selects a first group of cores to be in active status and a second group of cores to be in backup status;
The allocator, a core of the first group selected based on their position on the die, and supplies the communication data between the operating system (OS) core to the allocator, the allocator between the core of the communication data An apparatus that assigns, to a first group, a core having the smallest number adjacent to a core of the first group or a plurality of cores that are close to each other for a process of closely communicating with each other according to a data amount . The allocator selects one of the second group of cores to include in the first group of cores after one of the first group of cores fails.
The apparatus according to claim 9 . The allocator schedules a first process to a first core of the first group of cores, and schedules a second process to a second core of the first group of cores;
The first process and the second process communicate with each other;
The apparatus according to claim 9 or 10 . The multi-core processor further includes storage for storing core status information, and the core status information includes positions of the plurality of cores and corresponding status information.
12. A device according to any one of claims 9 to 11 . The allocator accesses the storage after one of the cores of the first group fails, and sets one core of the second group of cores to be reconfigured as the core of the first group. Select based on core status information,
The apparatus according to claim 12 . The allocator includes a dedicated core in the multi-core processor;
The apparatus according to any one of claims 9 to 13 . The allocator includes a microcontroller including a read only memory (ROM) that stores an allocation program;
15. A device according to any one of claims 9 to 14 . A program comprising instructions that, when executed by a machine, enable the machine, the instructions to an allocator,
Receiving inter-core communication data of the processor from an operating system (OS);
According to the data amount of the inter-core communication data, the minimum number of cores adjacent to the cores in the enabled state or a plurality of cores close to each other in the process of closely communicating with each other are assigned to the enabled state. When,
A program for executing a method including: The method further includes reducing the operating temperature of the processor by selecting at least one spare core using a temperature aware algorithm.
The program according to claim 16 . The method further includes selecting the at least one spare core to improve the performance of the processor, the processor including a multi-core processor.
The program according to claim 16 or 17 . The method performs a first process on the first core based on a distance between a first core of the enabled core subset and a second core of the enabled core subset. Further comprising assigning and assigning a second process to the second core, wherein the first process and the second process communicate with each other;
The program according to any one of claims 16 to 18 . A multi-core processor including a plurality of cores coupled through an interconnect fabric and a controller that assigns a first subset of cores to operations and a second subset of cores as spares;
A dynamic random access memory (DRAM) connected to the multi-core processor;
The controller assigns the first subset of cores based on an activation status of cores adjacent to the first subset of cores;
The controller receives inter-core communication data from an operating system (OS),
The controller has a minimum number of cores adjacent to the cores of the first subset according to a data amount of the inter-core communication data, or a plurality of cores close to each other for a process of closely communicating with each other Is assigned to the first subset ,
system. The controller, when one of the cores of the first subset fails, a core having the smallest number adjacent to the cores of the first subset of the cores of the second subset, Choose to include in the first subset of cores,
The system according to claim 20 . The controller schedules a first process to a first core of the first subset of cores and schedules a second process to a second core of the first subset of cores; Scheduling according to a temperature aware algorithm in one operating mode and not following the temperature aware algorithm in a second operating mode;
The system according to claim 20 or 21 . The controller further includes a storage for storing core status information, and the core status information includes activation status information corresponding to a position of the plurality of cores.
The system according to any one of claims 20 to 22 . The interconnect fabric may be reconfigured based on the first subset of core assignments;
24. A system according to any one of claims 20 to 23 . The controller includes a read only memory (ROM) that includes an allocation program;
25. A system according to any one of claims 20 to 24 . Receiving the core speed by the allocator via an intra-die variation probe for each of the plurality of available cores;
In response to the decrease in the core speed, connecting the spare core until the allocator reaches a preset performance goal;
The method according to any one of claims 1 to 8 further comprising a. The allocator receives the core speed via an intra-die variation probe for each of the plurality of cores;
In response to a decrease in the core speed, connect a spare core until the allocator reaches a preset performance goal;
The device according to any one of claims 9 to 15 . The allocator receives the core speed via an intra-die variation probe for each of the plurality of cores;
In response to a decrease in the core speed, connect a spare core until the allocator reaches a preset performance goal;
The program according to any one of claims 16 to 19 . Through the die fluctuation probes for each core of the plurality of cores, the controller receives the core speed,
With a decrease of the core speed, the controller connects the pre-core until it reaches the preset performance objectives,
The system according to any one of claims 20 to 25 .

Images