JP2006216058A - Data processing method, system and apparatus for moving processor tasks in multiprocessor system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To realize efficient distributed processing of processor tasks between multiprocessor systems on a network. <P>SOLUTION: A method and apparatus for moving and distributing processor tasks on a plurality of multiprocessor systems distributed through a network are provided. The multiprocessor system comprises at least one wide band engine 610. Each wide band engine 610 includes a plurality of processing units 630 and a synergistic processing unit 640 in addition to a shared memory 660. Tasks from one wide band engine 610 are remotely bundled, moved and processed in another wind band engine for effectively utilizing processing resources. The tasks are ended by being returned to the wide band engine 610 of the moving source, or subjected to continuous processing. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to a method and apparatus for managing processor tasks in a multiprocessor system distributed over a network, and more particularly, between sub-processing units of a multiprocessor system substantially self-governing. The present invention relates to a method and apparatus for scheduling and executing processor tasks via a network.

  This application is related to U.S. continuation patent applications 10 / 783,246 and 10 / 783,238, filed February 20, 2004, and filed on Feb. 4, 2005. Related to provisional application 60 / 650,153.

  Real-time multimedia applications are becoming increasingly important. These applications require extremely fast processing speeds, such as thousands of megabits of data per second. A single processing unit can achieve a high processing speed, but generally cannot match the processing speed of a multiprocessor architecture. In fact, in a multiprocessor system, a plurality of sub-processors can operate in parallel (or at least in cooperation) to obtain a desired processing result.

  Multiprocessor architectures are also useful, but scalability is limited. Greater efficiency can be achieved by grouping multiple multiprocessor systems over a network, and distributed processing is performed at a rate that exceeds the rate at which each multiprocessor system operates alone.

  The types of computers and computing devices that can use multiprocessor technology are extensive. In addition to personal computers (PCs) and servers, computing devices include mobile phones, mobile computers, personal digital assistants (PDAs), set-top boxes, digital televisions, and many others.

  Real-time multimedia software applications are composed of processing codes such as processing instructions and processing data. A collection of at least a portion of processing instructions and / or processing data can also be referred to as a processor task. Program statements in one processor task can be executed sequentially, another processor task can be executed in parallel on different processors in a multiprocessor system, or between different multiprocessor systems on a network It can also be dispersed. Thus, a software application can be considered to include a processor task that is executed by a multiprocessor system.

  A design concern for multiprocessor systems is how to manage which processor tasks are executed on which sub-processing units of the system, and how to manage the distribution of processor tasks among multiprocessor systems on a network It is. In some multiprocessor systems, a processor task designates which sub-processing unit's processor task is executed. The disadvantage of this method is that the programmer cannot optimize the distribution of processor tasks among the sub-processing units. For example, one or more processor tasks may specify the same sub-processing unit at the same time. This means that part of the processor task is suspended until the designated sub-processing unit is available, so that execution of the processor task is delayed. Unfortunately, this causes unpredictable latency for processor task execution.

  In other systems, consider that the management element communicates with the sub-processing units and schedules processor tasks between the units. Therefore, a communication protocol must be implemented to facilitate such communication. Unfortunately, communication protocols often cause message delays between management elements and sub-processing units. In fact, this type of protocol requires the use of memory mapped I / O space using memory mapped registers, which is generally slow. In addition, a management element, which may be the system's processor itself, uses a large number of split regions, which can require a significant amount of time (eg, 700 microseconds) to change. These features also delay the execution of processor tasks and cause unpredictable latencies. In this way, the overall processor throughput and efficiency of the multiprocessor system is sacrificed and can have a significant impact on the real-time and / or multimedia experience of the user of the system.

  Accordingly, there is a need in the art for a new method and apparatus that implements efficient distributed processing of processor tasks among multiprocessor systems on a network.

  A method and system for moving tasks from a first multiprocessor system to a second multiprocessor system over a network, such as the Internet, in accordance with an aspect of the present invention is provided.

  According to one aspect of the method, the multiprocessor determines whether to move a task from at least one multiprocessor for any of a variety of reasons. When the multiprocessor decides to move the task to another multiprocessor, it broadcasts the application from the first multiprocessor system. The application specifies a plurality of tasks and one attribute. The attribute represents the distance of the application from at least one of the previous multiprocessor that broadcast the application or the multiprocessor that first broadcast the application, and a deadline for ending each of the tasks. ing.

  According to another aspect of the invention, the attribute specifies the processing power required to perform the task. Furthermore, the same attribute or another attribute may specify the memory required to execute the task. An application can specify a plurality of tasks by owning a plurality of tasks or by using pointer information indicating a position where the task is located.

  According to another aspect of the invention, an application broadcast from a first multiprocessor system is received by a second multiprocessor connected to the network. The second multiprocessor unbundles the tasks in the application that includes the task to be moved. The second multiprocessor examines an attribute that specifies a requirement for executing the task and determines whether the task should be executed by the second multiprocessor. The second multiprocessor may check the required processing power and the required memory.

  According to another aspect of the invention, the second multiprocessor also examines the distance of the application from at least one of the previous multiprocessor that broadcast the application or the multiprocessor that originally broadcast the application, It is determined whether or not the task should be executed on the second multiprocessor system. The second multiprocessor preferably communicates to the first multiprocessor whether the second multiprocessor is performing a task. The “distance” here includes both a temporal distance and a spatial distance, and more specifically includes a latency, a band between applications, and the like.

  According to another aspect of the invention, the broadcast application is received by a plurality of other multiprocessors. Multiple other multiprocessors each distribute the task (s) to be moved included in the application. Each of the other multiprocessors examines an attribute that specifies a requirement for executing the task and determines whether or not the task should be executed. Preferably, each of the plurality of other multiprocessors includes a distance of the application from at least one of the preceding multiprocessor that broadcasts the application or the multiprocessor that initially broadcast the application, and each of the plurality of tasks. The deadline for ending the task is examined to determine whether or not the task should be executed.

  According to yet another aspect of the invention, an apparatus for moving a task is provided. The apparatus is a multiprocessor connectable to a network and programmed to determine whether the multiprocessor should perform a task or move to at least one multiprocessor connected to the network including. When it is determined that the task should be moved to at least one multiprocessor, the multiprocessor instructs the multiprocessor to broadcast the application via the network. The application specifies a plurality of tasks and one attribute, and this attribute indicates the distance of the application from at least one of the preceding multiprocessor that broadcast the application or the multiprocessor that first broadcast the application, and the plurality of attributes. And a deadline for ending each of the tasks.

  Other aspects, features and advantages of the present invention will become apparent to those skilled in the art from the present description taken together with the accompanying drawings.

  For the purposes of explanation, the presently preferred form is shown in the drawings, but it will be understood that the invention is not limited to the precise arrangements and instrumentalities shown.

  Referring to the drawings, wherein like numerals indicate like elements, FIG. 1 illustrates a multiprocessor system 100 in accordance with one or more aspects of the present invention. The multiprocessor system 100 includes a plurality of processors 102 (any number can be used) coupled to a shared memory 106 such as DRAM via a bus 108. Note that the shared memory 106 need not be a DRAM. Indeed, the shared memory can be formed using any known or later developed technology.

  One of the processors 102 is preferably a main processing unit, for example a processing unit 102A. The other processing unit 102 is preferably a sub-processing unit (SPU), such as processing units 102B, 102C, 102D. Sub-processing unit 102 may be implemented using any of the known or later developed computer architectures. Not all of the sub-processing units 102 need to be implemented using the same architecture; in fact, they can be either heterogeneous or homogeneous configurations. Note that main processing unit 102A may be located locally relative to sub-processing units 102B-102D, for example, on the same chip, the same package, the same circuit board, and the same product. Alternatively, the main processing unit 102A may be located in a different product that can be connected remotely to the sub-processing units 102B-102D, for example via a communication network such as a bus or the Internet. Similarly, the sub-processing units 102B-102D may be located locally or remotely from each other.

  By using the main processing unit 102A to schedule and orchestrate the processing of data and applications by the sub-processing units 102B-102D, the sub-processing units 102B-102D are independent of these data and applications in parallel. Execute the process. However, according to some aspects of the invention, main processing unit 102A does not play a central role in scheduling execution of processor tasks between sub-processing units. Rather, such scheduling is preferably left to the SPU itself.

  The assignment of roles and functions to the processor 102 of FIG. 1 is flexible. For example, any of the processors 102 may be a main processing unit or a sub processing unit.

  Referring to FIG. 2, main processing unit 102A preferably takes the role of a service processor for SPUs 102B-102F, particularly with respect to scheduling and management of processor tasks among SPUs. In accordance with some aspects of the present invention, main processing unit 102A can evaluate processor tasks included within the scope of a software application, and can allocate shared memory 106, SPU allocation, and shared memory 106 The initial storage of the processor task 110 can be involved. With respect to the allocation of shared memory 106, main processing unit 102A preferably determines the amount of memory space to be allocated to a given number of processor tasks 110. In this regard, main processing unit 102A allocates first area 106A of shared memory 106 for storage of some processor tasks 110 and second area 106B of shared memory 106 for storage of other processor tasks 110. May be assigned. The main processing unit 102A can also set rules regarding data synchronization in each of the areas 106A and 106B in the shared memory 106.

  In accordance with one or more further aspects of the present invention, only a defined number of sub-processing units 102 can be accessed in areas 106A and 106B of shared memory 106. For example, only sub-processing units 102 that are assigned to perform a particular processor task 110 stored in a given area of shared memory 106 can be accessed. For example, it is preferable that only the sub processing units 102 </ b> B to 102 </ b> D are permitted to access the processor task 110 in the first area 106 </ b> A of the shared memory 106. Similarly, it is preferable that only the sub processing units 102E to 102F are permitted to access the processor task 110 in the second area 106B of the shared memory 106. Further details regarding techniques for protecting each area 106A and 106B of the shared memory 106 can be found in US Pat. No. 6,526,491 entitled “Computer Architecture Memory Protection System and Method for Broadband Networks”, which All disclosures are incorporated herein by reference.

  In accordance with one or more aspects of the present invention, after the processor task 110 is located in the shared memory 106 and the sub-processing unit 102 is assigned to execute the task, the main processing unit 102A may execute the execution of the processor task 110. It is preferable not to participate in scheduling and management. Instead, those responsibilities are left to the specific sub-processing unit 102 involved.

  Before describing further details regarding the processor task management features of the various embodiments of the present invention, a preferred computer architecture for implementing a multiprocessor system will be described. In this regard, reference is made to the block diagram of the basic processing module or processor element (PE) 200 of FIG. According to this computer architecture, all sub-processors of a multiprocessor system are composed of a common computing module (or cell). This common computing module has a consistent structure and preferably uses the same instruction set architecture. In another embodiment of the invention, the sub-processing units may have different configurations. A multiprocessor system can be formed from one or more clients, servers, PCs, mobile computers, game consoles, PDAs, set-top boxes, devices, digital televisions, and other devices that use computer processors.

  The basic processing module is a processor element (PE). As shown in FIG. 3, the PE 200 includes an I / O interface 202, a processing unit (PU) 204, a direct memory access controller (DMAC) 206, and a plurality of sub processing units 208, that is, sub processing units. 208A, sub-processing unit 208B, sub-processing unit 208C and sub-processing unit 208D. A local (or internal) PE bus 212 transmits data and applications between the PU 204, sub-processing unit 208, DMAC 206 and memory interface 210. The local PE bus 212 can have, for example, a conventional architecture or can be implemented as a packet switch network. When implemented as a packet switch network, more hardware is required, but the available bandwidth can be increased.

  The PE 200 can be configured using various methods of implementing digital logic. However, the PE 200 is preferably configured as a single integrated circuit using complementary metal oxide semiconductor (CMOS) on a silicon substrate. Alternative materials for the substrate include gallium arsenide, gallium aluminum arsenic and so-called III-B composites using various dopants. The PE 200 can also be realized using superconducting materials, such as high speed single flux quantum (RSFQ) logic circuits.

  PE 200 is closely associated with dynamic random access memory (DRAM) 214 through high bandwidth memory connection 216. The DRAM 214 functions as a main memory (or shared memory) for the PE 200. DRAM 214 is preferably dynamic random access memory, but other means such as static random access memory (SRAM), magnetic random access memory (MRAM), optical memory, holographic memory, etc. It can also be realized using The DMAC 206 and the memory interface 210 facilitate the transfer of data between the DRAM 214 and the sub-processing unit 208 and PU 204 of the PE 200. Note that the DMAC 206 and / or the memory interface 210 may be located integrally or separately with respect to the sub-processing unit 208 and the PU 204. Indeed, instead of having separate configurations as shown, the functions of the DMAC 206 and / or the functions of the memory interface 210 may be integrated with one or more (preferably all) of the sub-processing unit 208 and the PU 204. .

  For example, PU 204 may be a standard processor that can process data and applications independently. Sub-processing unit 208 is preferably a single instruction multi-data (SIMD) processor. Sub-processing unit 208 preferably performs data and application processing in parallel or independently. The DMAC 206 controls access to data and applications (eg, processor task 110) stored in the shared DRAM 24 by the PU 204 and sub-processing unit 208. Note that the PU 204 may be implemented by one of the sub-processing units 208 taking on the role of the main processing unit.

  According to this modular structure, the number of PEs 200 used by a particular computer system is determined based on the processing power required by that system. For example, a server can use four PEs 200, a workstation can use two PEs 200, and a PDA can use one PE 200. The number of PE 200 sub-processing units allocated to handle a particular application depends on the complexity and size of the program and data in the cell.

  FIG. 4 shows the preferred structure and function of the sub-processing unit 208. The sub-processing unit 208 includes a local memory 250, a register 252, one or more floating point units 254, and one or more integer units 256. However, more or fewer floating point units 254 and integer units 256 may be used depending on the processing power required. Floating point unit 254 preferably operates at a rate of 32 billion floating point operations per second (32 GFLOPS) and integer unit 256 preferably at a rate of 32 billion operations per second (32 GOPS). Operate.

  In the preferred embodiment, local memory 250 includes 256 kilobytes of storage and the capacity of register 252 is 128 × 128 bits. Note that processor task 110 is not executed using shared memory 214. Rather, task 110 is copied to local memory 250 of a given sub-processing unit 208 and executed locally.

  The local memory 250 may or may not be a cache memory. Preferably, local memory 250 is configured as a static random access memory (SRAM). The PU 204 may require cache coherency support for direct memory access initiated by the PU 204. However, cache consistency support is not required for direct memory access initiated by the sub-processing unit 208 or access to external devices.

  The sub processing unit 208 further includes a bus interface (I / F) 258 for transmitting and receiving data and applications to and from the sub processing unit 208. In the preferred embodiment, the bus I / F 258 is coupled to the DMAC 206. The DMAC 206 is depicted with a dotted line in FIG. 3 to indicate that it can be located integrally within the sub-processing unit 208 or can be located externally. A pair of buses 268A, 268B interconnect the DMAC 206 between the bus I / F 258 and the local memory 250. Buses 268A, 268B are preferably 256 bits long.

  Sub-processing unit 208 further includes internal buses 260, 262 and 264. In the preferred embodiment, bus 260 has a width of 256 bits and provides communication between local memory 250 and register 252. Buses 262 and 264 provide communication between register 252 and floating point unit 254 and between register 252 and integer unit 256, respectively. In the preferred embodiment, the bus width of buses 264 and 262 from register 252 to the floating point unit or integer unit is 384 bits, and the bus widths of buses 264 and 262 from floating point unit 254 or integer unit 256 to register 252 are , 128 bits. Because the bus width from the register 252 to both units is larger than the bus width from the floating point unit 254 or integer unit 256 to the register 252, a larger data flow from the register 252 is accommodated during processing. A maximum of 3 words are required for each calculation. However, the result of each calculation is usually only one word.

  Returning to the various processor task management features of the present invention and referring to FIG. 2, to determine which processor task 110 should be copied from shared memory 106 to one of the local memory of SPU 102 for execution. The sub-processing unit 102 preferably uses a task table. In this regard, reference is made to FIG. FIG. 5 is a conceptual illustration of a task table 280 that can be used in accordance with various aspects of the present invention. The task table 280 is preferably stored in the shared memory 106. Details of the initialization method of the task table 280 will be described later. The task table 280 preferably includes a plurality of task table entries T1, T2, T3 and others. Each task table entry is preferably associated with one of the processor tasks 110 (see FIG. 2), eg, by associative addressing or other means of associating the task table entry with the processor task 110.

  In a preferred embodiment, each task table entry may include at least one of a status indication (STAT), a priority indication (PRI), and a pair of pointers (PREV, NEXT). STAT is an indication of whether the processor task associated with a given task table entry is ready (READY) or running (RUNNING) for execution by one or more sub-processing units Is preferably provided. The PRI preferably provides an indication of the priority of the associated processor task 110. The priority associated with processor task 110 may be any number, which may be set by a software programmer or later by execution of a software application. In any case, the priority of the processor task 110 can be used to set the order in which the processor tasks are executed. The PREV value is preferably a pointer to the previous task table entry (or previous processor task 110) in the ordered list of linked task table entries (or list of processor tasks). The NEXT value is preferably a pointer to the next task table entry (or processor task) in the ordered list of linked task table entries (or list of processor tasks).

  According to one or more aspects of the present invention, task table 280 is preferably utilized by sub-processing unit 208 to determine the order in which processor tasks 110 are copied from shared memory 106 for execution. . For example, to properly execute a software application on multiprocessor system 100 or 200, a particular processor task 110 is executed in a particular order, ie at least a general order, ie, T1, T8, T6, T9. May need to be done. To reflect this embodiment of the processor task array, the task table 280 preferably includes pointers in the PREV and NEXT portions of the task table entry that create a linked list of task table entries by the extended processor task. According to the particularity of the above example, task table entry T1 includes a NEXT value that points to task table entry T8. Task table entry T8 includes a PREV value that points to task table entry T1, and a NEXT value that points to task table entry T6. Task table entry T6 includes a PREV value that points to task table entry T8 and a NEXT value that points to task table entry T9. Task table entry T9 includes a PREV value that points to task table entry T6.

  With reference to FIG. 6, the linked list of task table entries in the above example can be conceptualized as a state diagram. In this state diagram, a transition from a particular processor task associated with task table entry T1 causes the selection and execution of another processor task associated with task table entry T8. The transition from the processor task associated with task table entry T8 causes selection and execution of the processor task associated with task table entry T6, and so on. Guarantees that the first or first task table entry T1 contains a PREV value that points to task table entry T9, and that the task table entry T9 contains a NEXT value that points to task table entry T1 By doing so, a circular association of task table entries (and / or the processor task itself) can be achieved.

  In operation, each sub-processing unit 102 assigned to execute a pool of processor tasks 110 in shared memory 106 (preferably in a given region 106A or 106B) has any processor task 110 for execution. Next, in order to determine whether it is occupied next, the task table 280 is first accessed. To help identify the first or first entry in the linked list, sub-processing unit 102 preferably has access to task queue 282, conceptually shown in FIG. The task queue 282 preferably includes an entry for the priority of each associated processor task 110. Each entry preferably includes at least one of a HEAD pointer and a TAIL pointer.

  Still referring to FIG. 6, an exemplary linked list state diagram represents a processor task 110 having a priority of 1. Indeed, the task table entries (FIG. 5) for entries T1, T8, T6 and T9 each contain a PRI value of “1”.

  The HEAD pointer and TAIL pointer of the task queue entry associated with priority 1 include pointers to task table entry T1 and task table entry T9, respectively. Other entries in task queue 282 are associated with other priority HEAD and TAIL pointers for other linked lists. Thus, various embodiments of the present invention can include multiple linked lists of task table entries (by extended processor tasks), each linked list including the same or at least similar priorities. Consider. Each sub-processing unit 102 preferably uses the task table 280 and task queue 282 to determine which processor tasks 110 should be copied from the shared memory 106 for execution. Assuming that each linked list is created and properly maintained, the processor tasks 110 can be executed in the appropriate order to achieve the desired results when the entire software application is executed.

  According to various aspects of the invention, sub-processing unit 102 maintains and modifies task table 280 and task queue 282 during execution of the software application. In this regard, reference is made to FIGS. These are flow diagrams representing process flows suitable for achieving one or more desirable features of the present invention. At action 300, a particular sub-processing unit 102 is called to begin copying processor task 110 from shared memory 106 to its own local memory. At action 302, sub-processing unit 102 locks task queue 282 and copies task queue 282 to its local memory. Thereafter, the task queue 282 is searched for a task with the highest priority ready (action 304). Using the example shown in FIG. 7, task queue 282 includes a HEAD pointer that points to task table entry T1 associated with the highest priority, eg, priority 1 processor task. Since the processor task associated with task table entry T1 is targeted for execution, sub-processing unit 102 preferably modifies task queue 282 to remove the reference to that processor task (action 306). . In the preferred embodiment, this will cause the HEAD pointer to task table entry T1 to be the new first (or first) task table entry that displays the next processor task to be occupied for execution. With modification to task table entry. In particular, the NEXT pointer of task table entry T1 may be used as a new HEAD pointer with priority 1. In fact, as shown in FIG. 6, when the processor task associated with task table entry T1 is running (RUNNING), it is no longer ready (READY) and must be removed from the state diagram. The task table entry T8 must remain as the first entry in the state diagram. When task table entry T1 is no longer part of the READY state diagram, the PREV pointer of task table entry T8 may be modified to point to task table entry T9. Thus, in action 308, the task table is labeled and copied to the local memory of the SPU 102 so that the task table can be modified. Similarly, the NEXT pointer of task table entry T9 may be modified to point to task table entry T8.

  According to a preferred aspect of the present invention, SPU 102 preferably modifies the STAT value of task table entry T1 from READY to RUNNING (action 310 in FIG. 9). As action 312, a determination is preferably made as to whether SPU 102 is executing the previous task when SPU 102 is called (action 300) to invoke the next task. This may occur when a previous task running on the SPU 102 yields to another task. For the purposes of this example, assume that the previous task did not yield to the next processor task 110 and that the result of the determination at action 312 was negative. Accordingly, the process flow preferably proceeds to action 318. Here, the SPU 102 writes the modified task queue 282 and the modified task table 280 back to the shared memory 106. At this point, task table 280 and task queue 282 are updated and unlocked according to the preferred synchronization technique so that it may be copied and modified by other sub-processing units 102.

  If the determination at action 312 is affirmative, such as when the previous processor task 110 has transferred execution to the next processor task, the process flow preferably proceeds to action 314. Therefore, the SPU preferably modifies the STAT value of the task table entry associated with the processor task to which the execution right is transferred from RUNNING to READY. In addition, the SPU may pre-load various task table entries including task table entries associated with processor tasks to which execution rights are transferred in order to reintroduce the processor tasks to which execution rights are transferred to the appropriate linked list. The pointer and the NEXT pointer may be modified. Preferably, this is accomplished by referring to the priority of the processor task 110 that transfers the execution right as reflected in the PRI value of the associated task table entry. At action 316, a processor task that transfers execution rights may be written to shared memory 106 so that the processor task may be occupied later. Thereafter, the process flow proceeds to action 318. Therefore, the task queue 282 and the task table 280 are written back to the shared memory 106.

  At action 320 (FIG. 10), the next processor task 110 (eg, the processor task associated with task table entry T8) is copied by the sub-processing unit 102 from the shared memory 106 to its own local memory. At action 322, the sub-processing unit 102 may restore and / or update its registers (eg, having any data associated with the new processor task) for use in executing the new processor task 110. preferable. Finally, at action 324, the new processor task 110 is executed by the sub-processing unit 102.

  The above actions are shown for illustrative purposes only, and those skilled in the art will appreciate that the order of these actions can be modified without departing from the spirit and scope of the present invention. For example, as described below, the order in which processor tasks are copied from shared memory and written back to shared memory, and the order in which task tables and task queues 282 are utilized, can be modified to achieve desirable results.

  As described above, the main processing unit 102A is preferably utilized during the initial stages of the system to prepare the system for execution and management of processor tasks 110 that can be handled by the sub-processing unit 102. . Sub-processing unit 102 also preferably executes an initialization routine to create task table 280 and task queue 282 in the first instance. These initialization processes are shown in the flow diagram of FIG.

  At action 350, a service processor (eg, main processing unit 102) evaluates a software application running on the system and assigns a plurality of sub-processing units 102 that perform processor task 110. The process flow preferably proceeds to action 352 where the service processor evaluates the software application and allocates one or more portions of the shared memory 106 to receive the processor task 110. At action 354, processor task 110 is loaded into shared memory 106 according to any memory allocation performed at action 352. At this stage of the initialization process, the service processor is preferably not involved in the maintenance and / or distribution of processor tasks among the sub-processing units 102.

Process flow preferably proceeds to action 356. Thus, the sub-processing units 102 initialize each other and determine which SPU prepares the task table 280 and task queue 282 in the first instance. In action 358, the sub-processing unit 102 responsible for creating the task table 280 and task queue 282 prepares this type of information and stores the same in the shared memory 106. For example, initialization of task table 280 and task queue 282 is preferably done by having each SPU kernel execute the first task. The program “init.c” shown below is a preferred embodiment of the first task executed by each SPU.

#include <spurs.h>
#include "task_instance.h"

int
main ()
{
spurs_beggin_init ();
if (spurs_get_spu_id () = = 0) {
spurs_create_task (melchior);
spurs_create_task (balthasar);
spurs_create_task (caspar);

spurs_start_task (melchior);
spurs_start_task (balthasar);
spurs_start_task (caspar);
}

spurs_end_init ();
return 0;
}

  In this program, “melchior”, “balthasar” and “caspar” are very early task names, which are typical startup tasks. All of the SPU kernels execute this initial task init.c. However, only one SPU (SPU having ID0) executes these tasks specified by the code line of if (spurs_get_spu_id () == 0). All other SPUs, for example all SPUs with different IDs, wait in spurs_end_init (). Thus, each SPU kernel executes the first task, and after this first task is finished, the SPU kernel begins searching for the next task as described herein.

  As noted above, it should be noted that the main processing unit 102 operating as a service processor may designate one or more processor tasks 110 as a group. This is preferably performed during the initialization phase. For example, two or more processor tasks 110 may need to communicate closely with each other, and therefore, processor tasks can be performed more efficiently when they are grouped within a task group. An encryption program is an example of an application that can include processor tasks that communicate more closely and execute more efficiently if the processor tasks are formed in one or more task groups.

  The processor task management features of the present invention can be used to help main processing unit 102A off-load a particular sub-processing unit 102 or group of sub-processing unit 102 device drivers. . For example, a network interface such as a Gigabit Ethernet handler (Ethernet is a registered trademark) can use up to 80% of the CPU power. If the network interface is executed only by the main processing unit 102A, the main processing unit 102A cannot be used for other service-oriented processing tasks. Thus, it may be beneficial for the main processing unit 102A to offload the network interface program to one or more sub-processing units 102. The main processing unit 102A may achieve this result by placing processing tasks for the network interface in the shared memory 106 and assigning one or more sub-processing units 102 to execute it. In response, the SPU may form a task table 280 and a task queue 282 suitable for managing and scheduling the execution of such processor tasks. Thus, advantageously, the main processing unit 102A can allocate more CPU power to the execution of other tasks. The main processing unit 102A may also offload other device drivers such as, for example, digital television device drivers. Other device drivers that are preferred candidates for offloading to the SPU are those with heavy protocol stacks. For example, drivers for real-time fast access devices such as HDD recorders are advantageously offloaded. Other examples of tasks that may be offloaded include network packet encryption / decryption tasks used for multimedia over virtual private networks and IP (eg, VoIP) applications.

  With reference to FIG. 12, an example of a state diagram of the status of the processor task is shown. Task states can be divided into five categories: run (RUNNING) state, ready (READY) state, block (BLOCKED) state, dormant (DORMANT) state, and absent (NON-EXISTENT) state. A processor task is in a running (RUNNING) state when it is currently running. Under certain conditions, a processor task can maintain an execution state, for example, during an interrupt, without a task context. The processor task is ready to execute the task, but one or more processor tasks with higher priority are already running and the sub-processing unit is not available due to task occupancy, When it cannot be executed, it is in a ready state. If the priority of a ready processor task is sufficiently high in the pool of ready tasks in shared memory 106, the sub-processing unit may occupy and execute that processor task. Thus, when a task is dispatched (dispatch), the state of the processor task may change from the preparation state to the execution state. Conversely, if this type of task is preemptively executed (preempted) or violated during its execution, the task in the running state may change to the ready state. An example of preemptive execution of a processor task has already been described in connection with the transfer of execution rights from one processor task to another.

  The block state category may include a wait (WAITING) state, a suspended (SUSPENDED) state, and a wait suspended (WAITING-SUPENDED) state. A processor task is in a WAITING state when the task is blocked because of a service call invocation that specifies that certain conditions must be satisfied before continuing execution of the task. Thus, the task execution state may change to a standby state when a service call is invoked. A waiting processor task may be released to a ready state when a specified condition is satisfied, thereby allowing the sub-processing unit 102 to subsequently occupy the task being processed. When a task is forcibly stopped (the task itself may be called), the processor task may enter the suspended (SUSPENDED) state from the running state. Similarly, a ready processor task may enter a suspended state by a forced action. When such a forced stop of the processor task is released, the suspended processor task may be resumed and enter the ready state. A processor task is in a WAITING-SUPENDED state when it is waiting for a condition that the task should satisfy and is forcibly suspended. Accordingly, a processor task that is in a suspended state may enter a waiting state when the processor task is forcibly suspended, where the processor task waits for a condition to be satisfied.

  A processor task is in a dormant state when the task is not running or has already finished its execution. A dormant processor task may enter a ready state under appropriate circumstances. The absence (NON-EXISTENT) state refers to a so-called virtual state in which the task does not exist in the system, for example, because the task has not yet been created or has already been deleted.

  If a task that has moved to the ready state has a higher priority (or priority) than a task in the running state, the task with the lower priority moves to the ready state and the higher priority task is dispatched to the running state It is preferable to move to. In this situation, lower priority tasks are preemptively executed by higher priority tasks.

  Non-preemptive priority-based task scheduling is based on the priority assigned to the processor task. If there are many processor tasks with the same priority, scheduling is performed on the basis of first-come, first-served (FCFS) coming first. This task scheduling rule may be defined using priorities among tasks based on task priority. If there are tasks that can be executed, at most, the same number of assigned sub-processing units 102 as high priority tasks are in the execution state. The rest of the tasks that can be performed are in a ready state. Among the tasks having different priorities, the task having the highest priority has a higher priority. Among tasks of the same priority, the processor task that enters the state that can be executed earliest (running or ready) has a higher priority. However, the priority between tasks of the same priority may change due to the invocation of several service calls. Preferably, when a processor task is given priority over other processor tasks, dispatching occurs immediately and the task moves to the running state.

  With reference to FIGS. 13 and 14, certain preemption features in accordance with certain aspects of the present invention are illustrated. As described above, a processor task in an execution state (eg, task A) may be preemptively executed, or the execution right may be transferred to another processor task (eg, task B) in a preparation state. As shown in FIGS. 13 and 14, the task A is executed by the sub-processing unit 102 until the execution right is transferred. At this point, the SPU kernel operates to copy task A to the shared memory 106 (save task A). Thereafter, task B is copied from the shared memory 106 to the local memory of the SPU (restore task B). Then, the SPU executes task B. While this technology enjoys relatively high performance for local memory usage and high bandwidth, there is task execution latency from the time when the execution right is transferred to the time when task B is not optimized.

  With reference to FIGS. 15 and 16, an alternative method according to a further aspect of the present invention is shown. In this scenario, task B may be copied from shared memory 106 to local memory of sub-processing unit 102 before task A is copied from local memory to shared memory 106. In this regard, the sub-processing unit 102 may execute the task A while taking actions to identify and read the task B from the shared memory 106 at the same time. This involves copying the task table 280 and task queue 282 from the shared memory 106 to the local memory of the sub-processing unit 102A and using them to identify the next ready task, task B. At the time of transfer of execution rights, the kernel of sub-processing unit 102A copies task A from local memory to shared memory 106, which involves modifying task table 280 and task queue 282 as described above. May be. Thereafter, the sub-processing unit 102 may occupy execution of task B. This technique greatly reduces the latency between the transfer of execution rights and the execution of task B, as compared to the techniques shown in FIGS.

  With reference to FIGS. 17 and 18, the latency between execution rights transfer and task B execution may be further reduced in accordance with one or more further aspects of the present invention. More specifically, up to the point of execution right transfer, sub-processing unit 102 may operate in a manner substantially similar to that described above with respect to FIGS. However, it is preferable that the sub-processing unit 102 starts execution of the task B after the execution right is transferred. Substantially simultaneously, the kernel of sub-processing unit 102 preferably operates to copy task A from the local memory of sub-processing unit 102 to shared memory 106. Since task B is executed immediately after the execution is transferred, the latency is greatly reduced as compared with the methods shown in FIGS.

  According to one or more aspects of the present invention, sub-processing unit 102 may maintain multiple processor tasks in local memory for execution. This is shown in FIG. To manage the execution of multiple processor tasks, the local memory may include multiple pages and page tables. The advantage of this method is that the latency can be further reduced. However, one drawback is that a considerable amount of space in the local memory is monopolized by the execution of process tasks.

  With reference to FIGS. 20-22, migration of processor tasks in accordance with one or more aspects of the present invention is illustrated. These figures show how a processor task, for example task B, is moved from sub-processing unit SPU1 to another sub-processing unit SPU2. The movement may be based on some condition, eg, each priority associated with each processor task. According to some aspects of the invention, the movement of a processor task from one sub-processing unit to another may not be preemptive. In other words, movement of processor tasks occurs naturally as a result of priority conditions and timing and is not based on any decision that causes movement.

  This non-preemptive movement can be demonstrated in the following example. Assume that processor task B is selected from shared memory 106 using a task table, and that this task table represents the priority order of processor tasks ready for execution. Task B is operating on the sub-processing unit SPU1. Similarly, it is assumed that the processor task C is selected from the shared memory 106 according to the task table and is operating on the sub-processing unit SPU2. Assume that when processor task B and processor task C are selected, higher priority processor task A is not ready for execution and therefore has not been selected for execution. However, assume that processor task A and processor task C are ready for execution of processor task A while they are operating.

  Referring to FIG. 21, processor task B may yield the right to execute sub-processing unit SPU1. This transfer action by processor task B may occur by a programmer who has determined that transfer of execution rights is beneficial to the overall execution of the software application. In either case, the sub-processing unit SPU1 responds to this transfer of execution rights by writing the processor task B to the shared memory 106 and updating the task table. The sub-processing unit SPU1 also accesses the task table and determines which of a plurality of processor tasks in the shared memory 106 should be copied and executed. In this example, the processor task A has the highest priority according to the task table, and therefore the sub-processing unit SP1 copies the processor task A from the shared memory 106 to its own local memory for execution. At this point, the sub processing unit SP1 executes the processor task A, and the sub processing unit SP2 continues to execute the processor task C.

  Still referring to FIG. 22, processor task C may transfer the execution right of sub-processing unit SPU2 to another processor task. Also, this transfer of execution rights may be invoked by program instructions and / or processor task C conditions. In either case, the sub-processing unit SP2 writes the processor task C back to the shared memory 106 and updates the task table. The sub-processing unit SP2 also accesses the task table and determines which of the processor tasks that are ready for execution is copied. In this embodiment, processor task B is ready for execution and has the highest priority among the plurality of processor tasks ready for execution. Therefore, the sub-processing unit SPU2 copies the processor task B from the shared memory 106 to its own local memory for execution.

  Comparing the processing status shown in FIG. 20 with the processing status shown in FIG. 22, it can be seen that the processor task B has moved from the sub-processing unit SPU1 to the sub-processing unit SPU2.

  23 and 24, the preemptive multitasking aspect of the present invention is shown. These aspects of the present invention are such that, for example, a lower priority processor task executing on a sub processing unit, eg, sub processing unit SPU2, is replaced preemptively by a higher priority processor task, eg, processor task A State good things. More specifically, the processor task B may be operating on the sub-processing unit SPU1, and the processor task C may be operating on the sub-processing unit SPU2 (FIG. 23). Thereafter, the higher priority task, that is, task A may be prepared for execution. This may occur due to some action by other sub-processing units of the system.

  For the sake of explanation, it is assumed that, for example, as a result of execution of the processor task B, the sub-processing unit SPU1 has changed the status of the task A to an execution state. As a result, the sub processing unit SPU1 preferably determines whether or not the priority of the processor task A is higher than any priority of the processor tasks operating on other sub processing units. In this simplified case, the sub-processing unit SPU1 determines whether the processor task A has a higher priority than the processor task C. If the priority is high, the sub-processing unit SPU1 starts replacing at least the processor task C with the processor task A. In other words, the sub processing unit SPU1 yields the sub processing unit 102 to the processor task C and gives it to the processor task A. In this regard, the kernel of the sub-processing unit SPU1 may issue an interrupt to the kernel of the sub-processing unit SPU2. In response to the interrupt, the sub-processing unit SPU2 may update the task table (FIG. 24) by writing the processor task C back to the shared memory 106. Sub-processing unit SPU2 may also copy processor task A from shared memory to its local memory for execution.

  With reference to FIGS. 25 and 26, a particular direct movement aspect of the present invention is shown. These aspects state that a higher priority processor task executing in one of the sub-processing units may be moved to another sub-processing unit executing a lower priority processor task. . This movement may be made in response to a direct interrupt received by a sub-processing unit executing a higher priority processor task. Referring to FIG. 25, the sub-processing unit SPU1 may receive an interrupt indicating that some other task must be performed. This interrupt may cause the sub-processing unit SPU1 to determine which of the other sub-processing units of the system is executing a lower priority processor task. In such a case, such a sub-processing unit may transfer the right to execute the processor task in support of a higher priority processing task. More specifically, when the sub processing unit SPU1 determines that the sub processing unit SPU2 is executing a processor task having a lower priority than the processor task A (for example, processor task B), the kernel of the sub processing unit SPU1 is It is preferable to issue an interrupt to the kernel of the sub-processing unit SPU2. In response to the interrupt, the sub-processing unit SPU2 writes back the processor task B from its local memory to the shared memory 106, and updates the task table. Sub-processing unit SPU2 also preferably copies (or moves) processor task A from the local memory of sub-processing unit SPU1 to its local memory for execution.

  FIG. 27 illustrates how a processing unit (PU) handles an interrupt according to one aspect of the present invention. In the first step, the PU receives an interrupt. The PU determines which sub-processing unit (in this case, a group of SPU0, SPU1, and SPU2) has the lowest priority. The PU then sends an interrupt to the SPU having the lowest priority. In the case of FIG. 27, since SPU2 has the lowest priority, the PU transmits an interrupt to SPU2.

  According to one or more further aspects of the present invention, an interrupt from one sub-processing unit to another sub-processing unit can be handled in a number of ways. With reference to FIG. 28, in one embodiment of the present invention, one sub-processing unit may be designated to manage interrupts to any of the other sub-processing units in the system. The designated sub-processing unit receives all such task movement interrupts and determines whether to process them themselves or pass the interrupt to another sub-processing unit. For example, when an interrupt is directed to a designated sub-processing unit, the designated sub-processing unit itself may process the interrupt. Alternatively, if the interrupt was not directed to the designated sub-processing unit, the designated sub-processing unit sends the interrupt to the sub-processing unit executing the lowest priority processor task. You may send it.

  FIG. 29 illustrates another way in which a distributed interrupt handling scheme is used. According to this technique, each interrupt is assigned to each sub-processing unit. For example, the interrupt A may be assigned to the sub processing unit SPU0. Interrupts B and C may be assigned to the sub-processing unit SPU1, and interrupts D, E, and F may be assigned to the sub-processing unit SPU2.

  In the description given with reference to FIGS. 23 to 26, it is necessary for the sub processing unit to be able to determine the priority of the processor task operating on the other sub processing units of the system. According to one embodiment of the present invention, the sub-processing unit may utilize a shared task priority table when determining the priority of the processor task being executed. The shared task priority table may be located in shared memory and may include multiple entries for sub-processing unit identifiers and processor task priority identifiers. For example, the sub-processing unit identifier may be a numeric and / or alphanumeric code unique to the sub-processing unit. The processor task priority identifier preferably indicates the priority of the particular processor task being executed. Each entry in the shared task priority table preferably includes a sub-processing unit identifier and priority identifier pair, which indicates the priority of a given processor task executing on the associated sub-processing unit. . In this way, a sub-processing unit that is trying to determine the priority of a running processor task accesses the shared task priority table and finds a sub-processing unit that is executing a lower priority processor task. May be. Preferably, the sub-processing unit executing the lowest priority processor task is identified and the execution right is transferred to the higher priority processor task.

  Other embodiments of the present invention provide that sub-processing units utilize a shared variable that indicates which sub-processing unit is executing the lowest priority processor task. The use of shared variables is preferably accomplished through an atomic update process so that an accurate indication of priority is assured. An alternative method may utilize a series of messages that are sent sequentially from one sub-processing unit to another. The message may be updated with a lower priority processor task priority identifier and sub-processing unit identifier.

  Referring to FIG. 30, another embodiment of the present invention reduces the number of sub-processing units 208 assigned to perform processor task 110 by combining multiple PEs 200 to enhance processing power. Consider that it may increase. For example, two or more PEs 200A, 200B may be packaged or combined into one or more chip packages to form a set of multiprocessor devices. This configuration may be referred to as a broadband engine (BE). The BE 290 includes two PEs 200A, 200B, which are interconnected for data communication via a bus 212. An additional data bus 216 is preferably provided to allow communication between the PEs 200A, 200B and the shared DRAM 214. One or more input / output (I / O) interfaces 202A, 202B and an external bus (not shown) provide communication between the BE 290 and any external elements. PEs 200A, 200B in BE 290 each perform data and application processing in a parallel and independent manner similar to the parallel independent application and data processing performed by sub-processing unit 208 described above with respect to FIG. . According to various aspects of the invention, a BE may comprise a single PE or multiple PEs. Further, the BE itself may include a plurality of BEs.

  Refer to FIG. Here, the stand-alone SPU 208, PE 200, or BE 290, which is a set of a plurality of PEs, may be distributed among a plurality of products as a basic structural unit to form the multiprocessor system 500. Elements or members of system 500, implemented as computers and / or computing devices, preferably communicate via network 504. The network 504 may be a local area network (LAN) or a global network such as the Internet or any other computer network.

  For example, members connected to network 504 may include, for example, client computer 506, server computer 508, personal digital assistant (PDA) 510, digital television (DTV) 512, or other wired or wireless wireless computers and computing devices. including. For example, client 506A may be a laptop computer comprised of one or more PEs 200 or other suitable multiprocessor system. Client 506B may be a desktop computer (or set-top box) comprised of one or more PEs 200 or other suitable multiprocessor system. Further, the server 508A may be an administrative entity using a database function, which is preferably composed of one or more PEs 200.

  Accordingly, the processing power of the multiprocessor system 500 may depend on multiple PEs 200 located locally (eg, on one product) or remotely (eg, on multiple products). In this regard, FIG. 30 is a block diagram of an overall computer network according to one or more aspects of the present invention. A BE 290 consisting of a PE 200 and / or multiple PEs can be utilized to implement the overall distributed architecture of the computer system 500.

  Server 508 includes more computer modules (eg, PE 200) than client 506 because server 508 of system 500 performs more data and application processing than client 506. On the other hand, the PDA 510 executes the minimum processing amount in this embodiment. Accordingly, the PDA 510 includes a minimum number of PEs 200, such as a single PE 200. The DTV 512 essentially executes the processing level between the client 506 and the server 508. Accordingly, the DTV 512 includes a number of PEs between the PEs of the client 506 and the server 508.

  Further details regarding the distributed multiprocessor system 500 will be described. The homogeneous configuration of system 500 promotes adaptability, processing speed, and processing efficiency. Since each member of system 500 performs processing using the same computing module, eg, one or more (or portions thereof) of PE 200, data and application processing may be shared by network members. The identification of computers and computing devices that perform processing of data and / or applications is not critical. By uniquely identifying a cell application that includes data and applications to be processed by the system 500, the processing results can be sent to the computer or computing device requesting the processing regardless of where the processing occurred. Since modules that execute processing have a common structure and use a common instruction set architecture, a calculation load due to an additional software layer for obtaining compatibility between processors is saved. This architecture and programming model facilitates, for example, the processing speed required to run multimedia applications in real time.

  In order to obtain further benefits of processing speed and processing efficiency facilitated by system 500, the data and applications processed by this system may be packaged into uniquely identified and uniformly formatted cell applications 502. Good. Each cell application 502 may or may include both applications and data. As described below, each cell application also includes an ID for identifying the cell throughout network 504 and system 500.

  The homogeneity of the structure of the cell application and the uniform identification of the cell application across the network facilitates the processing of applications and data on any computer or computing device in the network 504. For example, the client 506 may execute the cell application 502, but the cell application 502 may be transmitted to the server 508 for processing because the processing capability of the client 506 is limited. Accordingly, the cell application 502 can move throughout the network 504 based on the availability of processing resources on the network 504.

  The homogeneous structure of the processor and cell application 502 of the system 500 avoids many of the challenges of today's heterogeneous networks. Using an arbitrary instruction set, for example a virtual machine such as a Java virtual machine (Java is a registered trademark), inefficient program modules that attempt to allow processing of applications in any ISA are avoided. Thus, the system 500 can perform broadband processing more effectively and efficiently than conventional networks.

  According to one aspect of the method of the present invention, should the first multiprocessor (for convenience, eg, the first BE) move tasks from the first BE for any of a variety of reasons? Decide whether or not. For example, the first BE may determine that it is busy completing the task within a specified deadline or within a reasonable time period. If the first BE determines that the task should be moved to another processing system, it broadcasts the application from the first BE over the network. An application specifies or includes a plurality of tasks and a single attribute. The task to be moved is one of the designated task or the included tasks. The attribute indicates the distance of the application from at least one of the preceding BE that broadcast the application or the BE that first broadcast the application, and a deadline for ending each of the plurality of tasks. Is preferred. You can also specify a task queue. The application may directly specify a plurality of tasks by the application itself holding the task, or the application may indirectly specify the task using the pointer information. The pointer information is, for example, a pointer, index, or other equivalent technique, and represents or points to a location where the task is located. Alternatively, the attribute may be linked to any one of the task queue, each task, and a block of tasks combined with the attribute in the application. Further in accordance with an aspect of the present invention, a task has an attribute that specifies a requirement for performing the task. The attribute may be common to two or more tasks, or may be common to all tasks. Alternatively, each task may have a unique independent attribute.

  The “distance” of an application may refer to the physical distance that can be a measure of transfer latency, but preferably the network latency as it moves across the network to another location or processor. Refers to that.

  For example, the transmission source or “owner BE” decides to move the application A and broadcasts the application A to the network. The application A has a deadline, necessary calculation resources (for example, the number of SPUs or a plurality of tasks), and other parameters. Another cell, the first BE, receives application A and checks the parameters and the “distance” to the owner BE. For some reason, the first BE decides not to process application A and broadcasts application A back to the network. In this case, Application A's distance is still the network latency from the potential new BE to the owner BE. This time, the second BE receives application A and checks the parameters and the distance to the owner BE. Based on this information, the second BE may return the result of application A to the owner BE.

  Alternatively, the “distance” may be a distance from the immediately preceding BE instead of the transmission source, that is, the owner BE. For example, the owner BE decides to move the application A onto the network. The application A has a deadline, necessary calculation resources (for example, the number of SPUs or a plurality of tasks), and other parameters. The first BE receives application A and checks the parameters and the distance to the owner BE. For some reason, the first BE decides to move part of application A as “A ′” and broadcasts A ′ to the network. In this case, A 'distance is the network latency from the potential new BE to the first BE. A 'deadline is faster than application A. The second BE receives A 'and checks the parameters and the distance to the first BE. The second BE may return the result of A 'to the first BE. The first BE may generate a result for application A having A 'and return the result to the owner BE.

  The attribute preferably specifies the processing capability required to execute the task. Thus, if the processor architecture described above is used, this attribute may specify the number of SPUs required to perform the task. Further, the same attribute or different attributes may specify the amount of memory required to perform the task.

  An application broadcast by the first BE is received at a second BE connected to the first BE by the network. The second BE unbundles the tasks in the application and determines which tasks should be moved from the first BE. After determining the task to be moved and moved, the second BE should be executed by the second BE, preferably by a software command, examining attributes specifying requirements for performing the task. Determine the task. As described above, when describing the required processing power and required memory for the attribute (or attributes), the second BE preferably has the required processing power associated with the task being moved and Check the required memory.

  According to another aspect of the invention, the second BE also has an application distance from at least one of the preceding BE that broadcast the application or the BE that originally broadcast the application, and a plurality of tasks. A deadline for ending each of the tasks and a deadline for ending each of the plurality of tasks are examined. Then, it is determined whether or not the plurality of tasks should be executed by the second BE. The second BE preferably informs the first BE whether or not the second BE is performing the task (s).

  According to another aspect of the invention, the broadcast application is received by a plurality of other BEs. Each of the other BEs performs the steps described above for the second BE. Accordingly, each of the other BEs decomposes the task (s) in the application. The task or tasks to be moved are included in the application. Each of the plurality of other BEs examines attributes that specify requirements for executing the plurality of tasks to determine whether the task should be executed. Further, each of the plurality of other BEs is a distance from the application to at least one of the preceding BE that broadcasts the application or the BE that first broadcast the application, and the dead for terminating each of the plurality of tasks. And determine whether the task should be executed.

  In the above description, the first BE is defined as the first multiprocessor and the second BE as the second multiprocessor for convenience. However, it will be appreciated that each of the first and second multiprocessors may be any of the elements shown in FIG. Thus, by way of example, the first multiprocessor may be one of the clients 506 and the second multiprocessor may be another one of the clients 506 or the PDA 510. FIG. 32 shows a state in which a plurality of cells 502 are moving on the network 504. This is an application in which this cell 502 is transferred or broadcast between BEs in the above description. For example, a plurality of “cells” are drawn in the client 506, and this represents an image in which a cell application is executed in a plurality of BEs or PEs in the client 506. In addition to the client 506, a “cell” is also drawn in the server 508, but this does not necessarily represent an image in which the BE or PE in the server or client is executing the “cell”. It only indicates that the “cell” can be executed. Each PE may have an architecture as shown in FIG. 3 having a plurality of SPUs. However, it is understood that the present invention is applicable to any system having multiple networked processors, regardless of processor type or architecture.

  In this regard, FIG. 33 illustrates one embodiment of the cell server 600 of the present invention. One or more broadband engines (BE) 610 are managed by the cell server. Each BE has a local memory associated with each of the processing units (PUs) 630, a plurality of synergistic processing units (SPUs) 640, and advantageously a plurality of SPUs (shown in FIG. 4), similar to the environment described above. A basic processor element (PE) 620 comprising a logical storage device (LS) for use (accessed via the DMAC 650) and a shared memory 660. The BE internally communicates via the BE bus 670 and the BE input / output channel 675. In addition, the cell server has one or more network interfaces 680. The network interface is advantageously associated with each PU or SPU, but may be directly associated with the cell server. Advantageously, the cell server 600 includes a cell bus 690 for internal communication and a local cell input / output channel 695.

  Details of general purpose memory handling characteristics of one embodiment of BE are described in US patent application Ser. No. 09 / 815,554, filed Mar. 22, 2001, entitled “SYSTEM AND METHOD FOR DATA SYNCHRONIZATION FOR A COMPUTER ARCHITECTURE FOR BROADBAND NETWORKS”. Which is assigned to the assignee of the present application. A description of one embodiment of BE basic interconnection in a networked multiprocessor environment is described in US Provisional Patent Application entitled “METHOD AND APPARATUS FOR PROVIDING AN INTERCONNECTION NETWORK FUNCTION” filed on April 22, 2004. No. 60 / 564,647, which is assigned to the assignee of the present application.

  Each BE includes one or more BE tasks 700, as schematically illustrated in one embodiment of FIG. The BE task 700 is preferably organized in the shared memory of the cell server utilizing the task queue 710 and associated task tables 720a-720d. Each of the task tables 720a-720d comprises a set of task table entries (see FIG. 35), which has one or more SPU tasks to be executed by one or more SPUs (see FIG. 35). reference). The BE task preferably has a unique BE task identifier 730.

  In addition, each BE task preferably has at least the following four parameters. That is, the minimum number of SPUs required to execute a BE task or task group (minimum required SPU 730a), the memory size required by the BE task or task group (memory allocation 730b), cell latency, that is, own this BE The distance between the cell server and the receiving BE (cell latency 730c) and the task deadline (task deadline 730d) of the SPU task included in the BE task. The BE task preferably also includes other values (730e) required by the cell server network. An example of the BE task is shown in Table 1.

  FIG. 35 shows an embodiment of the task table of the present invention. As described above, each task table 740 includes a set of table entries 750 that hold one or more of the following parameters. That is, task status 760a, task priority 760b, other task table value 760c, previous task pointer 780, and next task pointer 790. Each task table 740 may have an instruction pointer 770 for the actual instruction to be executed.

  The task status 760a represents a state of the task, for example, any one of a task being executed, preparation, standby, standby interruption, interruption, suspension, and absence. Task priority 760b represents the level or importance of the task and is used to determine the execution order of tasks during scheduling. Previous task pointer 780 and next task pointer 790 are used in conjunction with other table entries 750 to form a linked list in task table 740. Previous task pointer 780 and next task pointer 790 also provide ordered access of processing tasks in the task table to the PU and SPU.

  FIG. 36 shows an embodiment of the BE task queue of the present invention. Each task queue 710 includes a set of head entry pointers 800 and tail entry pointers 810 for each of a plurality of task priority levels 820. Specifically, the task queue 710 provides a separate head entry for each of the n priority levels (0 to n-1) provided to prioritize execution of task instructions at the BE on the cell server. And tail entry pairs. In general, there are as many linked lists as there are priority levels. Thus, for each priority level, a linked list of tasks 830 at that priority level includes a head pointer 840 that points to the first task entry 845 in the task table 740 for that priority, and a task for that priority. Associated with a tail pointer 850 that points to the last task entry 855 in the table. An example of the task queue 710 is shown in Table 2.

  The PU and / or SPU uses the BE task queue and associated BE task table to perform task processing scheduling. Specifically, the order in which process tasks extracted from the shared memory are put into one of the SPUs for execution is determined. Each BE in the cell server preferably maintains at least one task queue and an associated task table.

  The task queue and task table for each BE can be transferred from one BE to another BE within the same cell server, or from one BE on a separate cell server connected over the network. Facilitates moving processor tasks to another BE. A processor task to be passed to another BE for execution is bundled in the application for movement. In general, an application includes one or more BE tasks wrapped with other information, as described in detail below. A cell server that manages a particular BE is generally considered the application owner of that BE.

  FIG. 37 illustrates one embodiment of a method for bundling applications for movement. In general, as in other situations, for example, when the processor load in a BE (or in a cell server's specific SPU) is high, or when a priority conflict occurs in a specific SPU, a specific cell server One BE moves an application containing a set of one or more BE tasks to another BE. In particular, bundling applications for movement involves a step process that is handled by the sending BE.

  During the normal task processing state 900, in a move determination step 910, the BE determines whether a move of a task is necessary, for example due to high processor load, low memory availability, and so forth. If the move is necessary, in the stop task step 920, the currently executing task 700 is stopped. In task update step 930, the current task queue 710 and task table 720 of the sending BE are updated in preparation for bundling. In a bundle step 950, the BE task to be moved is bundled with the application 940 for movement. Preferably, cell 940 includes not only BE task 700 to be moved (including information in task queue 710 and task table 720), but also task data 952 associated with the BE task. Advantageously, the application may be compressed or encrypted to a minimum application size as needed to ensure application security and verify application integrity. Subsequently, the task is moved to another BE by a move step 960 via the poll-response-move-return process shown in detail in FIG. When the moving process (and the return of the moved process) is completed, the BE returns to the continuation of task processing via the normal task processing state 900.

  FIG. 38 illustrates one embodiment of a process for moving a BE task from a sending BE to a receiving BE anywhere on a known cell server network. As described in the bundling step 950 of FIG. 37, after the BE tasks to be moved are bundled, the BE polls other BEs in a polling step 970. Preferably, a BE polls other BEs 610, both on the same cell server 600 and other known cell servers 972, on one or more cell server networks 974.

  Preferably, the polling step 970 is performed via a broadcast query to a known BE on the known cell server network shown in FIG. In one embodiment, the broadcast query message 980 takes the form of a network message that includes multiple values. Values include source cell server and BE indication 985a, task priority indication 985b of the task to be moved, required SPU and / or memory resource indication 985c, task deadline indication 985d of the task being moved. , And any other value 985e that would be advantageous to be transmitted by a broadcast query, including but not limited to. These values are stored in a task table that is part of the bundled application. These values may be described in other data structures as necessary.

  Returning to FIG. 38, in a query response receiving step 990, the sending BE in the sending cell server receives one or more responses from known BEs in the cell server network. As shown in FIG. 40, the query response preferably takes the form of a network message that includes a specific value. Specific values include response BE and cell server location display 1005a, response BE current task deadline display 1005b, current BE free SPU, processor load and / or memory load display 1005c, query response 1000 Including, but not limited to, any other broadcast response message value 1005d required, required or included within.

  Returning again to FIG. 38, in the receiving BE selection step 1010, the sending BE determines from the received query response 1000 which set of response BE moving tasks should be sent. This selection is based on the short cell latency or the shortness of the network topology between the receiving BE and the sending BE, the short time to the deadline of the task currently being executed on the receiving BE, and the receiving side. It is preferably based on a decision that takes into account some or all of whether the SPU and memory availability at the BE is sufficient. In move step 1020, the bundled task in application 940 is moved to the selected receiving BE 1030.

  When the application 940 is transmitted to the receiving BE, in the receiving BE task unbundling step 1040, the receiving BE 1030 advantageously distributes and processes the applications in the shared memory. At the receiving BE task processing step 1050, the receiving BE 1030 accesses the bundled task, data, task queue, and task table to execute the moved processing task.

  When the processing of the moved task is completed by the receiving BE in step 1050, the completed task, data, task queue, and task table are re-bundled to the application in the receiving BE rebundle step 1060, and the sender sends out The returning BE, typically the cell server that owns the moved BE task, is returned. When the finished task is received by the original sending BE in the sending BE end task reception step 1070, the sending BE in the task unbundling step 1080 releases the finishing BE task. Subsequently, in the end task update step 1090, the process related to the completed BE task is updated, and the general task processing state 900 is resumed. Advantageously, other important data such as messages 980, 1000, application 600, and task data 952 are encrypted by known algorithms such as, for example, AES standards, Blowfish, or RSA-based public key encryption algorithms. May be. Similarly, the messages, data structures and other features of the present invention are fingerprinted by a digest algorithm such as MD5, and tasks, task data, and messages are transmitted over unreliable networks and network protocols. Important data consistency may be ensured.

  FIG. 41 illustrates one embodiment of the secure server launch of the present invention. The cell servers 1100 interconnected by this network advantageously form a community of cell servers called server launches 1110. Preferably, the server launch is formed on a topology-free network, such as an IP (Internet Protocol) based network such as the Internet or an intranet. However, a sufficiently efficient and reliable network protocol can be used.

  Advantageous, as security is important when server launches exist on other open networks such as wireless networks, insecure local area networks, wide area networks, organized or topological intranets or the more general Internet The server launch may be secure with respect to the network on which it resides. In one embodiment, each cell server in the secure server launch uses a public key and a private key, and cell servers distributed over the network can have an encryption module 1120 (in one embodiment, public key encryption ( Applications and other messages can be sent, received and authenticated via the PKI) module). However, any type of encryption algorithm may be used such as an AES-based handshake or compression-encryption technique. Cell servers outside the known network 1130 are generally able to participate in the cell launch, but if they do not have the proper type of encryption module and proper authentication (ie, keys and / or signatures), a secure server launch. It is preferable to refrain from participating in.

  Although the invention herein has been described with reference to particular embodiments, it will be understood that these embodiments are merely illustrative of the principles and applications of the present invention. Accordingly, it will be appreciated that many variations can be made to the illustrated embodiments, and that other configurations can be devised without departing from the spirit and scope of the invention as defined by the appended claims. .

FIG. 2 illustrates a structure of a multiprocessor system according to one or more aspects of the present invention. It is a block diagram which shows storage of the processor task in a shared memory. FIG. 2 shows a preferred structure of a processor element (PE) of the present invention. FIG. 3 shows a structure of an exemplary sub-processing unit (SPU) according to the present invention. FIG. 6 illustrates an example of a processor task table that can be used in accordance with one or more aspects of the present invention. FIG. 6 is a state diagram of a linked list of processor tasks set by the task table of FIG. 5. FIG. 6 is a diagram illustrating an example of a task queue that can be used with the task table of FIG. 5 to manage execution of processor tasks. FIG. 5 is a flow diagram illustrating process steps that may be performed by a multiprocessor system according to one or more aspects of the present invention. FIG. 5 is a flow diagram illustrating process steps that can be performed by the multiprocessor system of the present invention. FIG. 5 is a flow diagram illustrating process steps that can be performed by the multiprocessor system of the present invention. FIG. 5 is a flow diagram illustrating process steps that can be performed by a multiprocessor system in accordance with various aspects of the present invention to initialize a processor task in shared memory. FIG. 6 is a state diagram illustrating different status states of a processor task in accordance with one or more aspects of the present invention. FIG. 6 is a block diagram illustrating a method in which processor tasks are copied from shared memory and written back to shared memory in accordance with one or more aspects of the present invention. FIG. 14 is a timing diagram illustrating latency processing associated with the copy and write-back technique of FIG. 13. FIG. 6 is a block diagram illustrating a method in which processor tasks are copied from shared memory and written back to shared memory in accordance with one or more aspects of the present invention. FIG. 16 is a timing diagram illustrating latency processing associated with the copy and writeback technique of FIG. 15. FIG. 6 is a block diagram illustrating a method in which processor tasks are copied from shared memory and written back to shared memory in accordance with one or more aspects of the present invention. FIG. 18 is a timing diagram illustrating latency processing associated with the copy and write-back technique of FIG. FIG. 6 is a block diagram illustrating a method in which processor tasks are copied from shared memory and written back to shared memory in accordance with one or more aspects of the present invention. FIG. 6 is a block diagram illustrating non-preemptive processor task movement in accordance with certain aspects of the present invention. FIG. 6 is a block diagram illustrating non-preemptive processor task movement in accordance with certain aspects of the present invention. FIG. 6 is a block diagram illustrating non-preemptive processor task movement in accordance with certain aspects of the present invention. FIG. 6 is a block diagram illustrating preemptive multitasking of certain aspects of the present invention. FIG. 6 is a block diagram illustrating preemptive multitasking of certain aspects of the present invention. FIG. 6 is a block diagram illustrating preemptive processor task movement in accordance with certain aspects of the present invention. FIG. 6 is a block diagram illustrating preemptive processor task movement in accordance with certain aspects of the present invention. FIG. 5 is a partial block diagram and partial flow diagram illustrating a specific processor interrupt technique in accordance with one or more aspects of the present invention. FIG. 6 is a partial block diagram and partial flow diagram illustrating processor interrupt techniques in accordance with one or more aspects of the present invention. FIG. 6 is a partial block diagram and partial flow diagram illustrating processor interrupt techniques in accordance with one or more aspects of the present invention. FIG. 2 is a diagram illustrating the structure of a processing system including two or more sub-processing units according to one or more aspects of the present invention. 1 is a system diagram of a distributed multiprocessor system according to one or more aspects of the present invention. FIG. FIG. 3 is a block diagram of a cell application that can be used with the multiprocessor unit of the present invention. It is a system diagram showing an embodiment of the present invention. FIG. 2 is a block diagram illustrating one embodiment of a broadband engine task of the present invention. It is a block diagram which shows one Embodiment of the task table and task entry of this invention. It is a block diagram which shows one Embodiment of the task queue of this invention. FIG. 4 is a partial flow diagram illustrating one embodiment of application bundling of the present invention. FIG. 4 is a partial flow diagram illustrating one embodiment of task migration of the present invention. It is a block diagram which shows one Embodiment of the broadcast query message of this invention. It is a block diagram which shows one Embodiment of the query response message of this invention. 1 is a system diagram illustrating one embodiment of a secure cell launch of the present invention. FIG.

Explanation of symbols

  600 cell server, 610 BE, 650 DMAC, 660 shared memory, 670 BE bus, 675 BE input / output channel, 680 network interface, 690 cell bus, 695 local cell input / output channel.

Claims (37)

A data processing method for moving a task from one multiprocessor to at least one multiprocessor via a network,
Decide whether to move a task from one multiprocessor to at least one multiprocessor,
Broadcasting an application from one of the multiprocessors when it is determined that the task should be moved to at least one multiprocessor;
The application specifies a plurality of tasks and one attribute, and the attribute is a distance of the application from at least one of the preceding multiprocessor that broadcast the application, or the multiprocessor that initially broadcast the application, and A data processing method characterized by representing a deadline for ending each of a plurality of tasks.   The data processing method according to claim 1, wherein the attribute specifies a processing capability necessary for execution of a task. Receiving the broadcasted application on a second multiprocessor;
Distribute the task specified in the application,
In the second multiprocessor, the method further includes examining an attribute designating a processing capability necessary for executing the task to determine whether or not the task should be executed in the second multiprocessor. The data processing method according to claim 2.   The second multiprocessor includes a distance from the application to at least one of the preceding multiprocessor that broadcasts the application or the multiprocessor that first broadcast the application, and a deadline for ending each of the plurality of tasks. And determining whether or not the task should be executed by the second multiprocessor. 4. The data processing method according to claim 3, wherein:   In the second multiprocessor, the method further comprises examining an attribute designating a memory required for executing the task to determine whether or not the task should be executed by the second multiprocessor. The data processing method according to claim 3.   The second multiprocessor includes a distance from the application to at least one of the preceding multiprocessor that broadcasts the application or the multiprocessor that first broadcast the application, and a deadline for ending each of the plurality of tasks. And determining whether or not the task should be executed by the second multiprocessor.   6. The method according to claim 3, further comprising: communicating whether or not the second multiprocessor is executing a task to the first multiprocessor. Data processing method.   The data processing method according to claim 1, wherein the attribute specifies a memory size necessary for execution of a task. Receiving the broadcasted application on a second multiprocessor;
Distribute the task specified in the application,
In the second multiprocessor, further comprising examining an attribute designating memory required to execute the task to determine whether the task should be executed on the second multiprocessor; The data processing method according to claim 8.   The data processing method according to claim 1, wherein the application specifies the plurality of tasks by holding the plurality of tasks.   The data processing method according to claim 1, wherein the application specifies the plurality of tasks by pointer information indicating a location where the task is located. Receiving the broadcasted application on a second multiprocessor;
Distribute the task specified in the application,
The method further comprises examining in the second multiprocessor an attribute that specifies a requirement to execute the task to determine whether the task should be executed on the second multiprocessor. Item 2. A data processing method according to Item 1.   The second multiprocessor includes a distance of the application from at least one of the preceding multiprocessor that broadcasts the application or the multiprocessor that initially broadcast the application, a deadline for ending a plurality of tasks, 13. The data processing method according to claim 12, further comprising: determining whether or not the task should be executed by the second multiprocessor.   14. The method of claim 9, 12 or 13, further comprising the second multiprocessor communicating to the first multiprocessor whether or not the second multiprocessor is performing a task. Data processing method. Receive broadcast applications on multiple other multiprocessors,
The task specified in the application is distributed to each of a plurality of other multiprocessors,
13. The method of claim 12, further comprising: examining, in each of a plurality of other multiprocessors, an attribute specifying a requirement for executing the task to determine whether the task should be executed. The data processing method described.   The distance of the application from at least one of the previous multiprocessor that broadcast the application or the multiprocessor that first broadcast the application, and the deadline for completing the tasks 16. The data processing method according to claim 15, wherein each of a plurality of other multiprocessors determines whether or not the task should be executed.   16. The data processing method according to claim 15, wherein a plurality of other multiprocessors communicate with the first multiprocessor whether or not a task is being executed. A data processing system for moving tasks,
Network,
A plurality of multiprocessors connected to the network;
Means for determining whether to move a task from one multiprocessor to at least one multiprocessor;
Means for broadcasting an application over a network from one of the multiprocessors when it is determined that the task should be moved to at least one multiprocessor;
The application specifies a plurality of tasks and one attribute, and the attribute is a distance of the application from at least one of the preceding multiprocessor that broadcast the application, or the multiprocessor that initially broadcast the application, and A data processing system representing a deadline for ending each of a plurality of tasks.   The data processing system according to claim 18, wherein the attribute specifies a processing capability necessary for execution of a task.   The data processing system according to claim 19, wherein the attribute specifies a memory size necessary for execution of a task. Means for receiving the broadcasted application on a second multiprocessor;
Means for distributing tasks in the application in a second multiprocessor;
Means for examining in the second multiprocessor an attribute designating a processing capability required to execute the task and determining whether the task should be executed by the second multiprocessor;
The data processing system according to claim 19, further comprising:   The second multiprocessor includes a distance from the application to at least one of the preceding multiprocessor that broadcasts the application or the multiprocessor that first broadcast the application, and a deadline for ending each of the plurality of tasks. The data processing system according to claim 21, further comprising means for determining whether the task should be executed by the second multiprocessor.   The second multiprocessor includes means for examining an attribute designating a memory required for executing the task and determining whether or not the task should be executed by the second multiprocessor. The data processing system according to claim 22.   The second multiprocessor includes a distance from the application to at least one of the preceding multiprocessor that broadcasts the application or the multiprocessor that first broadcast the application, and a deadline for ending each of the plurality of tasks. 24. The data processing system according to claim 23, further comprising means for determining whether or not the task should be executed by the second multiprocessor. Means for receiving the broadcasted application on a second multiprocessor;
Means for distributing tasks in the application in a second multiprocessor;
Means for examining in the second multiprocessor an attribute designating memory required to execute the task and determining whether the task should be executed on the second multiprocessor;
The data processing system according to claim 22, further comprising:   The second multiprocessor comprises means for communicating to the first multiprocessor whether or not the second multiprocessor is performing a task. The data processing system described in 1.   The data processing system according to claim 18, wherein the attribute specifies a memory size necessary for execution of a task.   The data processing system according to claim 18, wherein the application specifies the plurality of tasks by holding the plurality of tasks.   19. The data processing system according to claim 18, wherein the application designates the plurality of tasks by pointer information indicating a location where the task is located. A second multiprocessor connected to the network;
Means for receiving the broadcasted application on a second multiprocessor;
Means for distributing tasks in the application;
Means for examining in the second multiprocessor an attribute that specifies a requirement for executing the task and determining whether the task should be executed on the second multiprocessor;
The data processing system according to claim 18, further comprising:   The second multiprocessor includes a distance from the application to at least one of the preceding multiprocessor that broadcasts the application or the multiprocessor that first broadcast the application, and a deadline for ending each of the plurality of tasks. The data processing system according to claim 30, further comprising means for determining whether the task should be executed by the second multiprocessor.   32. The data processing system of claim 31, wherein the second multiprocessor further comprises means for communicating to the first multiprocessor whether the second multiprocessor is performing a task. Means for receiving the broadcasted application on multiple other multiprocessors;
Means for distributing tasks in the application with each of a plurality of other multiprocessors;
Means for examining in each of a plurality of other multiprocessors an attribute that specifies a requirement for performing the task and determining whether the task should be performed;
The data processing system according to claim 31, further comprising:   Each of the other multiprocessors terminates each of the tasks and the distance of the application from at least one of the previous multiprocessor that broadcast the application or the multiprocessor that first broadcast the application. 34. The data processing system according to claim 33, further comprising means for determining whether or not the task should be executed by checking the deadline.   34. The data processing system of claim 33, wherein the plurality of other multiprocessors comprise means for communicating to the first multiprocessor whether the task is being executed.   31. The data processing system of claim 30, wherein the second multiprocessor further comprises means for communicating to the first multiprocessor whether or not the second multiprocessor is performing a task. A data processing device for moving a task,
A multiprocessor connectable to a network, the multiprocessor programmed to determine whether to perform a task by the multiprocessor or to move to at least one multiprocessor connected to the network;
When said multiprocessor determines that the task should be moved to at least one multiprocessor, it instructs to broadcast the application from said multiprocessor over the network;
The application specifies a plurality of tasks and one attribute, and the attribute is a distance of the application from at least one of the preceding multiprocessor that broadcast the application, or the multiprocessor that initially broadcast the application, and A data processing device representing a deadline for ending each of a plurality of tasks.

Images