Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
  • G06F9/46—Multiprogramming arrangements
  • G06F9/48—Program initiating; Program switching, e.g. by interrupt
  • G06F9/4806—Task transfer initiation or dispatching
  • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
  • G06F9/485—Task life-cycle, e.g. stopping, restarting, resuming execution
  • G06F9/4856—Task life-cycle, e.g. stopping, restarting, resuming execution resumption being on a different machine, e.g. task migration, virtual machine migration
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
  • G06F9/46—Multiprogramming arrangements
  • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
  • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
  • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
  • G06F9/5033—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering data affinity
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
  • G06F2212/27—Using a specific cache architecture
  • G06F2212/271—Non-uniform cache access [NUCA] architecture

Definitions

• This shared thread state allows the system to schedule threads from a shared pool onto individual cores, allowing for rapid movement of threads between cores.
• the paper demonstrates and evaluates benefits of this architecture.
• PEVI processors and memory macros integrated onto a chip
• IRAM Intelligent RAM
• the computerized system includes at least a first processor and a second processor, each of the processors operatively interconnected to a memory adapted to store a set of data.
• the computer-implemented method includes monitoring data of a set which are processed as at least one of input data or output data by the first processor while executing. The computer-implemented method also includes instructing to interrupt an execution at the first processor and resume the execution at the second processor if, based on the monitoring, the second processor is found to be at a shorter distance than the first processor from the monitored data.
• the computerized system includes a plurality of processors, amongst which a first processor and a second processor, each of the processors operatively interconnected to a memory adapted to store a set of data to be processed by a processor.
• the computer-implemented method includes monitoring data of the set which are processed as at least one of input data or output data by the first processor while executing.
• the computer-implemented method includes instructing to interrupt an execution at the first processor, the first processor in a given processor state, and resume the execution at the second processor, starting from a processor state at least partly determined by the given processor state.
• FIG. 1 is a flowchart of one embodiment of a method for managing processing resources of a computerized system
• FIG. 2 is a more detailed flowchart, illustrating a specific embodiment of a method for managing processing resources of a computerized system
• FIG. 3 illustrates schematically one embodiment of the
• FIG. 4 is a schematic representation of a computer system implementing one embodiment of a method for managing processing resources of a computerized system.
• FIGS. 5 and 6 are variant embodiments to FIG. 4.
• a computer-implemented method for managing processing resources of a computerized system breaks a classical paradigm according to which processors are the center of the world and input/output data are brought to/from the processors.
• embodiments of the computer-implemented method propose to move the "compute" state information to where the data is, e.g. by moving a core state to a closest core, instead of moving data to CPU. Basically, this results in moving Kbytes instead of Mbytes in practice.
• DIMM dual in-line memory module
• I/O input/output
• FIG. 1 is a flowchart of one embodiment of a method for managing processing resources of a computerized system.
• the method aims at proposing a new way of management of processing resources in a computerized system wherein several processors are operatively interconnected to a memory.
• the latter is adapted to store a set of data, which may be used by one or more of the processors.
• the data at stake is read ('input data') and/or generated by the core and written back (Output data').
• the method comprises two major steps, which are discussed now.
• step 100 First, input and/or output data processed by a first one of the processor are monitored, step 100.
• the data monitored can be input and/or output data.
• embodiments hereafter are based on examples of monitoring input data only, i.e. data read by the processor, for the sake of simplicity only. Yet, be it input and/or output data, principles of the invention remain the same.
• Instruction is resumed at a processor that is at a shorter distance from the monitored data.
• the distance at issue can for instance be a measure of how far a processor is from the data it processes.
• CPU cores are on 3D stacks with memory: here the distance from a given core to its respective memory is physically short, whereas distance to the memory of another 3D stack is much larger. More generally, the distance at issue reflects a cost, e.g. a cost of energy or time.
• the distance may further reflect a cost of time.
• the distance considered can vary like a latency (or an expected latency) of data to reach a given processor.
• Latency i.e. access time
• Latency is the time the memory delays in providing back data that a processor asks for. Roughly, the farther to a processor, the longer it takes to reach it. Waiting reduces the processor performance: if a processor has to wait five memory clock cycles to receive data it asks for, its performance will only be 1/5 of the performance it would have if it were using memory capable of immediately delivering data. Thus, resuming execution at a closer processor may result in better performances.
• the distance to given data can be estimated based on their memory addresses and the processor locations.
• monitoring input data accessed by a first processor may be carried out based on the memory addresses of the input data as stored on
• interconnects e.g. a bus.
• the last 100 memory addresses accessed are monitored. If it turns that e.g. a majority of the monitored addresses pertains to a memory or a memory sector closer to a second processor, then it is decided to resume execution at the second processor.
• Monitoring which data is accessed by a processor can else be performed via the processor's registers or other means.
• the distance can be determined as a vector involving several data read/written by the first processor (e.g. the last 100 read/write memory addresses), in order to determine whether the second processor is closer than the first processor.
• the controllers at stake can be software, or hardware, e.g. a hardware circuit. In the latter case, the hardware circuit is suitably interconnected to both the processors and memory (e.g. via one or more switches).
• the control logic may further be centralized (one controller decides) or distributed, i.e. several controllers (e.g. one per processor) may competitively decide, as shall be illustrated later.
• the memory cache does not have Nl readily available to answer PI 's request (the size of a cache line is typically 64 bytes - 1 Kbytes).
• LI shall successively query memory locations where different parts ofNl are stored (e.g. in contiguous blocks), in order to properly feed PI while executing.
• the addresses of the parts of Nl are accordingly logged e.g. in a bus (or in some other interconnect). Meanwhile, the stored addresses are monitored (the same would happen with output data, instead of input data). If such addresses correspond to a remote memory location, closer to another processor P2, then execution is moved to P2, as recited above.
• embodiments of the method can very well apply without cache memory at all.
• principles of embodiments of the method remain the same if no cache is used, i.e. when a processor directly queries the input data in the memory. For instance, addresses of the queried data can be monitored in essentially the same way.
• registers of the processor can be contemplated as an infra-level of cache, "closer" to the processor, such that the above example extends to a case where no cache memory (in the usual sense) is relied upon.
• some of the processors may have cache memory, while one or more other processors do not.
• the processors having cache memory may serve to cover setup of computation at other processors, in the same way that main memory serves processor for initial cold misses.
• execution can begin at P I (the latter equipped with cache), and when a more suitable processor Pn is found, moved to the latter (most suitable processors are not known beforehand).
• P I the latter equipped with cache
• Pn the processors are not known beforehand.
• a seamless transition can for instance be achieved by resuming execution at the second processor, starting from a processor state which is (at least partly) determined by that of the first processor, i.e. when execution was interrupted.
• the "processor state” usually refers to a state of the processor as reflected at some point in time by (at least) the processor registers, including e.g. the state flags. More broadly, it may refer to processor registers, latches and memory (e.g. the cache memory), or more. Typically, the code executed at the processor and input data accessed by the processor are part of a current state of this processor.
• a subset of the register data is imported in the second processor, in those cases where state information data are known to be partly the same. However, it remains that the state of the second processor at resuming is at least partly determined by the first (initial) processor's state.
• state information data can be populated with part or all the data from processor registers of the first processor and e.g. conveniently formatted, prior to import them to the second processor.
• any data suitably capturing part or all of processor states can be relied upon (hereafter state information data, or state data for short).
• state information data or state data for short.
• execution at the second processor is resumed after loading some convenient state information data in the second processor, the key point remaining to move the "compute" state data to the (input/output) data, rather than moving the data to the compute.
• FIG. 2 shows a more detailed flowchart, illustrating a detailed embodiment of a method for managing processing resources of a computerized system.
• lazy migrations can be contemplated, in order to further improve the efficiency of the scheme of the embodiment described in relation to FIG. 1.
• it can be instructed to populate (step 112) state data from registers of the first processor; the loading of the populated data starting before actually interrupting execution at the first processor (steps 112, 114).
• a controller may scan the processor's registers, identify the most persistent state data and decide to move such data to a closer processor.
• an early version of the first processor's state is sent to the second processor.
• a delta file is sent which codes the differences between the early and very last state.
• very few data need be moved in fine (a few Kbytes or less), ensuring fast transitions.
• step 1 14 Upon completion of the migration (step 1 14), execution can be resumed (step 130) at the second processor.
• Embodiments of the present invention allow for safely getting rid of data caches, inasmuch as high memory bandwidth allows for very short connections. Yet, it doesn't necessarily need to be so in practice.
• a further refinement is obtained by migrating a cache used by the first processor, in addition to the state data.
• the "environment" of the first processor is thus more completely recreated at the second processor.
• data of a memory cache storing copies of the data the most frequently accessed by the first processor can be written (step 1 16) in a memory cache used by the second processor.
• the synchronization would preferably be the same as that used for the state data, for consistency.
• the memory cache migrated is typically the smallest, i.e. LI memory cache used by the first processor. More efficient, one memory cache (LI) can be relied upon, instead of the usual LI - L3 trilogy. Indeed, the high memory bandwidth achieved in embodiments of the invention allows for safely removing data caches. In addition, relying on e.g. 'through silicon via' or TSV technology allows for very short connections. Incidentally, the freed up area can be used for more cores.
• the compute core state can itself be treated like a line in a cache.
• the compute core has Kbytes of state. Hence, execution can be suspended at a first processor, and core registers and LI cache be moved to a more appropriate core.
• the processor state of the first processor can be maintained until other state data are loaded therein (step 1 12'). This could for instance be a default behavior. Again, the controller could ensure updating the state at the first processor via a delta file, in due time and if necessary.
• the first processor can be turned off (step 140) after a temporization delay, if no new state is instructed to be loaded therein. Power consumption is thereby optimized.
• the best suited scale of computational tasks to be interrupted and resumed depends e.g. on the reactivity of the monitoring algorithm. Finding the most efficient scale depends on the context, the number of processors, the architecture, the type of processes, tasks, the nature of the input data, etc. Provided that an efficient monitoring scheme is available, the invention is advantageously implemented at the scale of a single thread of execution. One would accordingly instruct to continue a thread of execution at the second processor (step 130) after suspending a thread of execution at the first processor (step 120).
• a thread of execution can be seen as a part of a running task.
• a thread is contained inside a process and several threads may occur within a same process, sharing resources such as memory, at variance with processes. It is known from multithreading techniques, how to make a single processor switch between different threads (as in multitasking). Similarly here, embodiments of the invention make a thread to stop at one processor. Yet, instead of resuming it at the same processor, the thread is continued at another.
• FIG. 3 This point is illustrated in FIG. 3.
• the y-axis is the timeline.
• the two parallel lines inside the circle denote a respective processor, PI and P2.
• the thread t belongs to a given process p.
• a thread t is started and executed at PI .
• the controller detects that PI is using resources closer to P2 and decides to interrupt the thread t, the processor PI being in state si .
• the thread t is then resumed at P2, starting from the state s 1. Execution continues until the thread terminates or even, is interrupted at P2 (in state s2) to be imported back to PI, as illustrated in FIG. 3, and this, if the context makes it advantageous. Details as to thread management can for instance be found in the publication cited above, namely "Adaptive Data Placement in an Embedded Multiprocessor Thread Library.”
• embodiments of the present invention allow for moving computation state to memory instead of having a collection of hierarchical caches moving the data from main memory.
• some embodiments of the method are performed under hardware control (the controller is embodied as a hardware circuit), for transparency to software.
• FIG. 4 is a schematic representation of a computer system implementing one embodiment of a method for managing processing resources of a computerized system.
• processors PI - PN are connected to a memory M via suitable interconnects B, the latter comprising a bus B or a crossbar and possibly a switch. They are otherwise connected to a memory D (e.g. hard-disk), and under control of controller C.
• switches are distributed, e.g. one switch per core or subset of cores.
• controller C is part of the interconnect. In all cases, the controller C is suitably coupled to processors and memory such as to be able to instruct to move execution from one processor to another.
• FIG. 5 is a variant embodiment to FIG. 4, wherein controllers CI - CN are distributed amongst the processors, e.g. one controller Cn per processor.
• controllers may concurrently decide to move/receive processor states from one processor to another.
• a test based on monitoring input data, which is performed at CI, may thus lead to move PI state to P2.
• C2 may then decide whether to accept, based on a current activity (or state) of P2. For instance, if P2 is inactive, then C2 confirms moving PI state to P2.
• switches may be distributed.
• FIG. 6 is another variant embodiment to FIG. 4, wherein the memory now comprise at least two memory chips Ml, ...M , each of the first and second processors PI , P2 being a processor core operatively interconnected to a chip Ml , M2 of the memory, such as a DIMM, the controller interconnected to the processors via suitable interconnect.
• the memory now comprise at least two memory chips Ml, ...M , each of the first and second processors PI , P2 being a processor core operatively interconnected to a chip Ml , M2 of the memory, such as a DIMM, the controller interconnected to the processors via suitable interconnect.
• the processors PI - PN are in some embodiments quad- core arrangement on top of respective 3D memory stack Ml - MN, e.g. DIMM memory chips.
• the overall principle remains however the same: if, in operation, a first, given core of PI (let call it PI 1), turns to access a given data d frequently, the controller may move the PI 1 state to one core of P2.
• a goal hereby achieved is to put a reasonable amount of computing very close to DRAM and exploit 3D stacking e.g. with 'through silicon via' (TSV) technology, leading to packages which are faster, smaller and consume less power, together with a truly distributed system.
• TSV 'through silicon via'
• processor cores are on respective DIMM memory buffers.
• An application concerns for instance a database scan, wherein processors must inspect a large fraction of memory.
• the sequence of operations may for instance be the following:
• the memory scans begin and counters monitor the memory accesses.
• a "lazy" migration code is began between the DIMMs (i.e. the controller instructs to start loading state data at a second processor core before instructing to interrupt execution at a first core);
• the controller triggers migration of a thread state and halts execution on the first core.
• the method at least partially solves the memory bandwidth problem, as well as memory capacity problems.
• the principles at the core of some embodiments of the method are furthermore inherently scalable. Also, since some embodiments of the method enable fewer levels of cache, they are therefore simpler in nature.
• the approach proposed herein although it may require adapting the OS and memory controller design in some cases, is transparent to at least some applications. Yet, adapting the OS is not inherently necessary. Furthermore, adapting the memory controller is to include additional hardware for e.g. monitoring accesses per core and for migrating execution from one processor to the other and this, when the controller is embodied as a hardware circuitry. However, in a "software" only implementation of the method, no adaptation is required.
• instruction operations that the controller performs may be implemented in programs that are executable on a system including at least two programmable processors.
• Each computer program may be implemented in a high-level (e.g. procedural or object-oriented) programming language, or in assembly or machine language if desired; and in any case, the language may be a compiled or interpreted language.
• Suitable processors include, by way of example, both general and special purpose microprocessors.
• instruction operations that the controller performs may be stored on a computer program product tangibly embodied in a machine -readable storage device for execution by a programmable processor; and method steps of the invention may be performed by a programmable processor executing instructions to perform functions of the invention. In all case, the present invention encompasses the resulting computer system.
• embodiments of the above method may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them.
• a processor will receive instructions and data from a readonly memory and/or a random access memory.
• Storage devices suitable for tangibly embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto -optical disks; and CD-ROM disks or the like.
• the present invention is advantageously applied to large computers, with up to thousands of processors, high-speed interconnects, and specialized hardware.

Landscapes

• Engineering & Computer Science (AREA)
• Software Systems (AREA)
• Theoretical Computer Science (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Memory System Of A Hierarchy Structure (AREA)
• Multi Processors (AREA)
• Hardware Redundancy (AREA)
• Debugging And Monitoring (AREA)

Priority Applications (3)

Applications Claiming Priority (2)

Publications (2)

Family

ID=43982369

Family Applications (1)

Country Status (5)

Cited By (1)

Families Citing this family (21)

Family Cites Families (16)

• 2009
  • 2009-12-10 US US12/635,544 patent/US8473723B2/en active Active
• 2010
  • 2010-12-07 CN CN201080055635.1A patent/CN102652309B/zh active Active
  • 2010-12-07 GB GB1207124.7A patent/GB2488260B/en active Active
  • 2010-12-07 WO PCT/IB2010/055626 patent/WO2011070506A2/en active Application Filing
  • 2010-12-07 DE DE112010004735.9T patent/DE112010004735B4/de active Active
• 2012
  • 2012-08-30 US US13/599,102 patent/US8549268B2/en not_active Expired - Fee Related

Non-Patent Citations (6)

Also Published As

Similar Documents

Legal Events