KR101794696B1 - Distributed processing system and task scheduling method considering heterogeneous processing type - Google Patents

Abstract

The present invention relates to a task scheduling method in consideration of a heterogeneous processing type and a distribution processing system which comprise the following steps of: allowing a worker node to allocate a task to a first processing unit or a second processing unit based on the number of desired simultaneous performance in the second processing unit; allowing the worker node to monitor a use rate of the second processing unit; and allowing the worker node to change the number of desired simultaneous performance in accordance with the use rate.

Description

[0001] DISTRIBUTED PROCESSING SYSTEM AND TASK SCHEDULING METHOD CONSIDERING HETEROGENEOUS PROCESSING TYPE [0002]

The present invention relates to a task scheduling method and a distributed processing system considering heterogeneous processing types, and more particularly, to a task scheduling method and a distributed processing system in which a task to be performed in a distributed processing system such as Hadoop is dynamically allocated to a heterogeneous processing unit of a node, To a task scheduling method and a distributed processing system in consideration of heterogeneous processing types capable of improving the processing speed of tasks.

With the advent of the big data age, distributed processing in a distributed processing system such as Hadoop has become essential for efficient processing of big data. Traditionally, most of the data was text, but in recent years video data is rapidly increasing due to the rapid spread of security cameras and the emergence and spread of smart devices that record video. In addition, the video resolution is steadily increasing to 4K and the 1080p resolution is already common in CCTV.

On the other hand, as robust machine learning algorithms have been developed, attempts have been made to apply such algorithms to video processing. And video analytics applications can be easily found in many areas. For example, face detection and face recognition are available for marketing purposes as well as security and commercial applications. Most machine learning algorithms are compute-intensive and require a lot of time for a single frame.

In this manner, efficient video data processing has become essential. On the other hand, the GPU (Graphic Processing Unit) is gaining popularity due to its tremendous computing power, especially for video processing. However, in a distributed processing system, one GPU or several GPUs on one machine can not achieve maximum performance at present.

The distributed processing system, Hadoop framework, is composed of a plurality of nodes, and each node includes a GPU as well as a CPU. There is a continuing work on using the GPU to get higher throughput in the Hadoop framework.

Typical nodes in the Hadoop framework include an average of more than 10 CPU cores and GPUs, but previous studies utilizing GPUs have shown that when the GPU is in operation (by the GPU mapper, GPU kernel) Idle state, the performance of the CPU core is not utilized as much as possible.

The GPU mapper processes tasks on the GPU, and the host running on the CPU simply launches the GPU kernel. In this case, since the host does not perform computation-intensive processing, the CPU of the node is mostly in a dormant state. In this way, it is necessary to utilize the CPU resources while maximizing the performance of the node while utilizing the GPU.

The biggest problem to enable CPU-GPU hybrid scheduling in distributed processing system, Hadoop framework, is that the number of mapper (map task) in the node is fixed and unchangeable during job execution. Therefore, it is difficult to obtain CPU-GPU hybrid performance efficiently and dynamically.

A specific study (non-patent document 1) extends the Hadoop framework and uses both the CPU and the GPU of the node to reduce the execution time of the job. This study also assumes that only one task can be used on the GPU device regardless of the utilization of the GPU, so that it is impossible to maximize the performance of the GPU and the CPU by simplifying the scheduling.

The study is also configured to bind and schedule tasks to available slots on all available nodes of a job tracker. To do this, the task tracker on the node sends the slot availability of each node to the job tracker via a heartbeat message. This research has the problem that the scheduling is centralized by the job tracker and the existing Hadoop scheduling technique must be changed.

Also, in the specific invention (Patent Document 1), similar to the non-patent document 1, a task tracker is disclosed that schedules a task to a CPU or a GPU, but the same problem as the non-patent document 1 is presented.

Thus, there is a need for a task scheduling method and a distributed processing system considering heterogeneous processing types that can overcome the limitations of existing research and invention in a distributed processing system having heterogeneous processing types.

KR 10-1620896 B1

 Shirahata, K., Sato, H., Matsuoka, S. "Hybrid map task scheduling for GPU-based heterogeneous clusters" (2010) Proceedings - 2nd IEEE International Conference on Cloud Computing Technology and Science, CloudCom 2010, art. no. 5708524, pp. 733-740.

Disclosure of the Invention The present invention has been made in order to solve the above problems, and it is an object of the present invention to improve the job performance of a node by dynamically allocating a task to a heterogeneous processing unit of each node in a distributed processing system composed of nodes having heterogeneous processing types And to provide a task scheduling method and a distributed processing system considering heterogeneous processing types.

In addition, the present invention provides a task scheduling method and a distributed scheduling method considering heterogeneous processing types, which can provide maximum processing performance of a node while utilizing existing scheduling techniques in a distributed processing system by performing task assignment to a heterogeneous processing unit at a node The purpose of the system is to provide.

Another object of the present invention is to provide a task scheduling method and a distributed processing system considering heterogeneous processing types capable of balancing load among heterogeneous processing units reflecting the utilization rate and processing speed of heterogeneous processing units.

In addition, the present invention provides a task scheduling method and a distributed processing system considering heterogeneous processing types that can improve the task processing speed by maximizing the usage rate of the GPU among CPU and GPU, which are heterogeneous processing units, by using FSM (Finite State Machine) The purpose is to provide.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are not restrictive of the invention, unless further departing from the spirit and scope of the invention as defined by the appended claims. It will be possible.

According to another aspect of the present invention, there is provided a method for scheduling a task in consideration of a heterogeneous processing type, the method comprising: a worker node assigning a task to a first processing unit or a second processing unit based on a concurrent execution count in a second processing unit; The step of the node monitoring the utilization rate of the second processing unit and the step of changing the number of simultaneous execution of the worker node according to the usage rate.

In order to achieve the above object, a distributed processing system considering heterogeneous processing types includes at least one worker node for processing a task, each of the worker nodes includes a CPU including a plurality of CPU cores, a plurality of GPU cores And the node manager assigns tasks to the CPU or the GPU based on the utilization rate of the GPU or the desired number of simultaneous execution in the GPU. .

The task scheduling method and the distributed processing system considering heterogeneous processing type according to the present invention as described above dynamically allocate a task to a heterogeneous processing unit of each node in a distributed processing system composed of nodes having heterogeneous processing types, There is an effect that the performance can be improved.

In addition, the task scheduling method and the distributed processing system considering the heterogeneous processing type according to the present invention as described above perform task assignment to the heterogeneous processing unit in the node, and utilize the existing scheduling technique in the distributed processing system, And the like.

In addition, the task scheduling method and the distributed processing system in consideration of the heterogeneous processing type according to the present invention can balance the load among the heterogeneous processing units by reflecting the utilization rate and the processing speed of the heterogeneous processing unit.

In addition, the task scheduling method and the distributed processing system in consideration of the heterogeneous processing type according to the present invention can maximize the utilization rate of the GPU among the CPU and the GPU, which are heterogeneous processing units, using the FSM (Finite State Machine) There is an effect that can be improved.

The effects obtained by the present invention are not limited to the above-mentioned effects, and other effects not mentioned can be clearly understood by those skilled in the art from the following description will be.

1 is a diagram showing an exemplary system block diagram of a distributed processing system.
2 is a hardware block diagram of a worker node.
3 is a functional block diagram of a worker node.
4 is a diagram showing an example of a load imbalance occurring according to dynamic scheduling and a corresponding example thereof.
5 is a diagram illustrating an exemplary dynamic scheduling process of tasks that perform a requested job.
6 is a diagram illustrating an example of a variable used in the dynamic scheduling process and an FSM for dynamic scheduling.

The above and other objects, features and advantages of the present invention will become more apparent from the following detailed description of the present invention when taken in conjunction with the accompanying drawings, in which: It can be easily carried out. In the following description, well-known functions or constructions are not described in detail since they would obscure the invention in unnecessary detail. Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings.

1 is a diagram showing an exemplary system block diagram of a distributed processing system. Figure 1 shows an example of a Hadoop framework for partitioning a requested job into multiple tasks and configuring the divided tasks to be performed at each node 10. [ Through the distributed processing system of Fig. 1, it is possible to process a job that targets a large amount of data at a high speed.

1, a distributed processing system, such as the Hadoop framework, is comprised of a communication network for transmitting data transmitted and received between a plurality of nodes 10 and a node 10.

The node 10 can process jobs of a Map / Deuce program model that can be processed by a distributed processing system, such as the Hadoop framework. The node 10 may be or be a device capable of executing programs, such as a personal computer, a server, a workstation, or the like.

This distributed processing system can be used for various applications in various fields such as performing video processing job, analyzing big data or generating statistics.

One or more nodes 10 of the plurality of nodes 10 constituting the distributed processing system (Hadoop framework) can generate a processing job (Job) of the MapReduce program model and can be a client node that requests processing on the distributed processing system have. In order to distinguish it from other types of nodes, the client node is denoted by reference numeral 100 below.

The other node or nodes 10 may be a master node that receives a job processing request from the client node 100 and allocates a task to process this job and a split to process in the task according to the job processing request. To distinguish it from other types of nodes, the master node is denoted 200 hereafter.

The master node 200 determines a worker node to process this job upon receipt of a job processing request from the client node 100 and sends a split corresponding to the tasks to be performed in each worker node to each worker node via a communication network .

For example, the master node 200 assigns one or more worker nodes to a requested job and also assigns one or more tasks to each worker node according to the allocatable resources of the distributed processing system. The master node 200 may divide the input file to be processed by the total number of tasks and divide it into splits having the same size and communicate the split to be split to the worker node performing the corresponding task via the communication network.

For example, if there are five assignable worker nodes and each worker node has or can have five tasks, the master node 200 will have 25 tasks to process the requested job and a split to process in each task To configure, the input file can be split into 25 splits of the same size. Each splitted split can be passed or notified to the task of the mapped worker node. The master node 200 may be referred to as a job tracker node depending on the version of the Hadoop framework.

Another plurality of nodes 10 may perform the task (map task and / or reduce task) of the requested job in the corresponding split according to the instruction of the master node 200 and may be a worker node have. In order to distinguish it from other types of nodes 10, the worker node is denoted by reference numeral 300 hereinafter. The worker node 300 may be referred to as a task tracker node depending on the version of the Hadoop framework.

The master node 200 divides the input file to be used in the requested processing job into splits of equal size and allocates the split split to the worker nodes 300 for performing this processing job and transmits the allocated split over the communication network To each of the worker nodes (300). The splits allocated to the specific worker node 300 and the splits allocated to the other specific worker node 300 are different and the splits are allocated to the same size.

The client node 100, the master node 200, and the worker node 300 do not necessarily have to be mapped to different physical machines.

Each node 10 can send and receive necessary data through SSH (Secure Shell) data communication on a distributed processing system (Hadoop framework) and can share files through HDFS (Hadoop Distributed File System).

The communication network on the Hadoop framework may be a short-range communication network or a broadband communication network. The communication network may constitute an Internet network, for example.

FIG. 2 is a hardware block diagram of the worker node 300. FIG.

2 may represent a block diagram of the master node 200 or the client node 100 as well as the worker node 300 or may be a master node 200 or a client node 100 ) Can be constructed.

2, the worker node 300 includes a communication interface 301, a memory 303, a mass storage medium 305, a system bus / control bus 307, and a CPU 309 and a GPU 311 .

The communication interface 301 is an interface for transmitting or receiving various data through a communication network. The communication interface 301 includes a communication chip capable of accessing a wired LAN and / or a wireless LAN, and can transmit and receive communication packets through a communication network. Through the communication interface 301, the worker node 300 can access the split (allocated) mapped to the task of the worker node 300 via the HDFS or receive the split from the master node 200 or the like, It can also receive or access.

The memory 303 includes volatile memory such as SDRAM and / or nonvolatile memory such as NAND flash to permanently or temporarily store various data and programs.

For example, the memory 303 may temporarily store the split to be handled by the task, or permanently or temporarily store the node manager 350 program and / or the task program executed by the CPU 309 or the GPU 311 . A program stored in the memory 303 or the like (particularly, the node manager 350 program) will be described in more detail with reference to the functional block diagram of FIG.

The mass storage medium 305 stores various data and programs including one or more hard disks and the like. The mass storage medium 305 may store a node manager 350 program and / or a task program, and may further store a split or the like. The mass storage medium 305 may be omitted according to the design variant.

The system bus / control bus 307 sends and receives data between blocks. The system bus / control bus 307 may be configured in one or more combinations of a parallel bus, a serial bus, a general purpose input output (GPIO), a local area communication network such as a wired LAN / wireless LAN,

The CPU 309 can execute programs stored in the memory 303 or the mass storage medium 305, including a plurality of CPU cores 309-1. Each of the CPU cores 309-1 included in the CPU 309 can perform a program independently from the other CPU core 309-1 and access the memory 303 and the like. Each of the CPU cores 309-1 can perform a task (hereinafter, also referred to as a CPU task) assigned to the CPU 309. [

The GPU 311 may execute a program stored in the memory 303 or the mass storage medium 305, including a plurality of GPU cores 311-1. Each of the GPU cores 311-1 included in the GPU 311 can independently execute programs and access to the memory 303 or the like with other GPU cores 311-1. Each of the GPU cores 311-1 can perform a task assigned to the GPU 311 (hereinafter also referred to as a GPU task).

As can be seen from the above, the worker node 300 has at least processing units of different processing types, and each of the heterogeneous processing units can independently execute a task program that performs the same function. One type of processing type of processing unit may be the CPU 309 and another type of processing type of processing unit may be the GPU 311. Each of the GPU cores 311-1 includes a plurality of microprocessing units capable of independently performing operations, so that it is possible to expect faster processing than the CPU core 309-1.

The CPU 309 and the GPU 311 can load various programs included in the memory 303 or the like and can independently process them and perform the assigned task on the splits that are mapped to the assigned tasks and split from the input file .

The various processes and flows in the worker node 300 will be described in more detail below with reference to FIG.

FIG. 3 is a functional block diagram of the worker node 300. FIG.

According to FIG. 3, the worker node 300 includes a node manager 350 and one or more tasks performed on the hardware block diagram of FIG. 2, and the specific worker node further includes an application master. At least one worker node 300 of the plurality of worker nodes 300 processing the same job may assign the task to another worker node 300 including this application master. This application master can receive an assignment task from (the resource manager of) the master node 200 and distribute it to its own or another worker node 300. Herein, the functional blocks of the worker node 300 are indicated by numbers of 350 to distinguish them from the codes of the hardware blocks.

The functional block diagram of FIG. 3 is performed on the hardware block diagram of FIG. 2 and is performed on the CPU 309 or the GPU 311 of the worker node 300 in the form of a program. Thus, the worker node 300 includes not only the hardware block according to FIG. 2 but also the software (function) block according to FIG.

Referring to FIG. 3, the node manager 350 manages the worker node 300. The node manager 350 sends a task assigned to the worker node 300 by the master node 200 to the worker node 300 constituted by the memory manager 303 or the node manager 350 program stored in the mass storage medium 305. [ To the CPU 309 or the GPU 311 in accordance with the resource status of the resource management unit 300 so that the corresponding task is executed in the assigned processing unit. Tasks assigned by the master node 200 may be assigned to this worker node 300 via the application master.

The node manager 350 may assign an assigned task to the CPU 309 or the GPU 311 based on the usage rate of the GPU 311 and / or the number of concurrently performing tasks, (311).

For dynamic task allocation, the node manager 350 includes at least a GPU monitor 351 and a dynamic scheduler 353.

The GPU monitor 351 is configured to monitor the utilization of the GPU 311. The GPU monitor 351 can acquire the usage rate of the GPU 311 through a library or the like. For example, the GPU monitor 351 can acquire the GPU utilization rate through NVIDIA's Management Library. The GPU usage rate obtained through the library may represent a percentage of the time that the GPU 311 is used or may indicate the usage rate of the GPU cores 311-1 within the GPU 311. [

The GPU monitor 351 may calculate the percentage of the usage time of the GPU 311 or the usage percentage of the GPU core 311-1 used in the entire GPU core 311-1 of the GPU 311, Obtain GPU utilization.

The dynamic scheduler 353 may assign a desired task assigned from the master node 200 to the desired number of concurrently executed and / or GPU usage rates obtained by the GPU monitor 351 that are dynamically changed and initialized by the dynamic scheduler 353 And allocates it to the CPU 309 or the GPU 311.

The dynamic scheduler 353 includes a finite state machine (FSM) and the FSM is used to assign a task assigned to the worker node 300 to the CPU 309 or the GPU 311. The FSM is triggered according to the event associated with the assigned task or triggered according to the specified period. The event related to the assigned task may be a case where a new task is assigned through the master node 200 or a task to which the task is assigned is completed in the CPU 309 or the GPU 311. [ The designated period may be, for example, 100 mSec, 500 mSec, 1 second, or the like.

The dynamic scheduler 353 allocates the assigned task to the CPU 309 or the GPU 311 by utilizing various variables used in the FSM. For example, the dynamic scheduler 353 sets the maximum number of simultaneous execution (max_gpu) variables that are the maximum number of simultaneously executable tasks in the GPU 311 according to the assignment policy, Is set to the desired number of simultaneous execution in initialization, initial setting, or specific state.

The maximum number of concurrent tasks to be set first is set based on the total number of tasks assigned to the worker node 300 in the job of the specific job request and the CPU usage rate of the task allocated to the GPU 311. [

The dynamic scheduler 353 initializes the task execution current number variable executed in the current GPU 311 according to the initialization of the FSM and allocates the assigned task to the GPU 311 to increment the task execution current number variable by 1, Lt; / RTI > In addition, as the task assigned to the GPU 311 is completed, the dynamic scheduler 353 decrements this variable by one.

The dynamic scheduler 353 allocates tasks and changes or manages the variables to obtain the maximum performance of the GPU 311 by using the correlation between the desired number of simultaneous execution, the current number of task execution, and / or the GPU usage rate.

For example, the FSM of the dynamic scheduler 353 may set the number based on the current number of tasks being performed in the current GPU 311 when the GPU usage rate obtained through the GPU monitor 351 is equal to or greater than a specified (set) Change to the desired number of execution. For example, the dynamic scheduler 353 sums the number (e.g., 1) specified in the task execution current number, and changes the summed value to the concurrent execution desired number.

This change in the desired number of concurrent operations is made on the state transition on the FSM and is dynamically performed according to the GPU usage rate and the number of tasks allocated to the current GPU 311. [ The desired number of simultaneous execution is set to the maximum number of simultaneous execution according to the initial allocation policy, and then converges to a value capable of obtaining the maximum performance according to the assignment and execution of the task.

The node manager 350 can forcibly assign the currently assigned task to the GPU 311 based on the number of tasks already performed for the requested job.

The GPU task (mapper) is very fast compared to the CPU task execution time, and at the end of the requested task, the dynamic scheduling can lead to serious load imbalance.

For example, if a newly arrived split is the last split and assigns a task corresponding to this split to the CPU 309, the other task or GPU 311 waits for the end of the long running time according to the assignment of the CPU 309 of this task A problem occurs.

In order to deal with such a load imbalance, the node manager 350 continuously updates the number of assigned tasks (splits), and if the number of allocated tasks (splits) exceeds the set threshold, Can be forcibly assigned to the GPU 311. [

As another alternative, the node manager 350 allocates a new task to the GPU 311 according to the following equation according to the allocation of the new task (split).

Here, N represents the total number of tasks (splits) to be processed in the worker node 300, b represents the total number of tasks that have been assigned to the CPU 309 for the current job, and X represents a GPU Represents the number of tasks, and Y represents the number of CPU tasks set to be simultaneously executable.

P represents the ratio of the execution time of the CPU 309 and the GPU 311 and can be expressed, for example, as "execution time of CPU task / execution time of GPU task ". The node manager 350 can calculate the execution time of the CPU task and the execution time of the GPU task by acquiring the execution time ratio in advance or allocating and executing the task.

For example, after assigning a new task to the CPU 309, the node manager 350 measures the start and end times of the CPU task to calculate the execution time of the CPU task, The execution time can be calculated. In addition, after the node manager 350 assigns a new task to the GPU 311, the start time and the end time of the GPU task are measured to calculate the execution time of the GPU task. Further, the execution time of the GPU tasks is averaged, Can be calculated. Then, the node manager 350 can calculate and continuously update P by using the (average) execution time of the CPU 309 and the GPU 311 measured.

In this way, when the number of tasks already performed is equal to or greater than a specified threshold in consideration of load balancing, or when the above-mentioned equation (1) based on the number (b) of tasks that have already been performed is satisfied, the node manager 350 assigns a new task to the CPU To the GPU 311 without assigning it to the GPU 309, and perform the task. The node manager 350 may skip the operation of the FSM of the dynamic scheduler 353 or the dynamic scheduler 353 when a new task is forcibly assigned to the GPU 311. [

The dynamic scheduler 353 will be described in more detail below with reference to FIG.

The node manager 350 creates one or more tasks and each task is performed on the designated CPU 309 or the GPU 311. A task (map task) assigned to the CPU 309 is executed on the CPU core 309-1 and a task assigned to the GPU 311 is executed on the GPU 311 core 311-1. The worker node 300 may have a plurality of containers capable of instantiating a fixed number of tasks. The container may be an object, for example, composed of software. The node manager 350 can instantiate a new task in a container and assign it to the CPU 309 or the GPU 311 when there is a container that does not have a task.

The task assigned to the CPU 309 is executed in the CPU core 309-1 on the CPU 309 and the task assigned to the GPU 311 is executed in the GPU 311 core 311-1 on the GPU 311 do.

5 is a diagram illustrating an exemplary dynamic scheduling process of tasks that perform a requested job.

Each step of FIG. 5 is performed by the node 10 and preferably by a program executed by the CPU 309 of the node 10 or the GPU 311.

First, the master node 200 is connected to one or more client nodes 100 and receives a job processing request from the client node 100 through a communication network (S101).

For example, the resource manager of the master node 200 may receive a job processing request for performing a specific function from the client node 100 connected through the communication network. The received job processing request may be a job that can be performed in parallel or independently for a large-capacity file. For example, the job processing request may be independent operation processing, statistical analysis, video processing, and the like for each data included in a large-capacity file.

The resource manager of the master node 200 that has received the job processing request determines the worker nodes 300 available on the distributed processing system and determines the number of tasks to be allocated in each of the determined worker nodes 300 and the input (S103). ≪ / RTI >

One task corresponds to one split and is configured to process the split. Thus, in the sense of allocating a split, it can mean assignment of tasks, and vice versa.

The resource manager of the master node 200 distributes (S105) the split corresponding to the task via the communication network to the worker nodes 300 that will process the job through the communication network.

For example, a resource manager may request processing of a task partitioned into application masters configured on one of the worker nodes 300 of the plurality of worker nodes 300, and the application master may request the node manager 350 of each of the plurality of worker nodes 300, And assigns the task to the worker node 300 in cooperation with the worker node 300.

The node manager 350 of the worker node 300 assigns the assigned task to the first processing unit (CPU 309) or the second processing unit (e.g., GPU 311) (see S107 to S119) .

In accordance with the task assignment, the worker node 300 can assign a newly entered task to the first processing unit or to the second processing unit, and the node manager 350 Initializes various variables for dynamic scheduling (S107).

For example, the node manager 350 (or the dynamic scheduler 353) first sets a concurrently executing maximum number variable (max_gpu in FIG. 6) that indicates the maximum number of tasks that are preset and can be performed simultaneously in the second processing unit.

The maximum number of concurrent operations can be set differently according to the Assignment Policy. When the worker nodes 300 of the distributed processing system such as the Hadoop framework have a first processing unit such as CPU 309 and a second processing unit whose type is different from that of the first processing unit such as GPU 311 It is necessary to maximize performance of both types of processing units.

If too many tasks are assigned to the second processing unit, a performance degradation occurs due to the occurrence of the collision, and if too many tasks are assigned to the first processing unit, the performance degradation likewise occurs.

A major problem in the Hadoop framework that maximizes the performance of various processing types of processing units is that the number of tasks assigned to each worker node 300 is predetermined (see S103) and is not changeable in real time. Therefore, according to the allocation policy, the maximum number of concurrent processes is set first, and then the number of tasks of the second processing unit or the first processing unit is dynamically changed based on the maximum number or the number of concurrently executed tasks according to the monitored performance. There is a need to comply with the task partitioning policy of

In general, the processing units of one of the two processing units can provide higher performance than the other processing units. For example, the task of the GPU 311 of the second processing unit (hereinafter, a combination of the GPU and the term of the second processing unit) is executed by the CPU 309 of the first processing unit And uses a combination of terms). Therefore, the dynamic scheduler 353 of the node manager 350 sets the maximum number of simultaneous executions so that more tasks are initially allocated to the GPU 311 than the CPU 309 possible.

The following four allocation policies are proposed for setting the maximum number of concurrent operations,

1) Dynamic-preProfile: The number of best GPU tasks is acquired before a job is performed on a distributed processing system such as Hadoop. For example, prior to the execution of a job, the job is performed in advance and the number of GPU tasks, X, is increased to find the best value.

The number (Y) of CPU tasks is obtained by the following equation.

Here, TC represents a CPU utilization percentage (for example, 1200 if 12 CPU cores 309-1) of the worker node 300, and GC represents the CPU utilization of the GPU task. The GPU task generally involves the use of the CPU 309 to use the GPU 311 by the kernel performed by the CPU 309. X + Y may represent the total number (N) of tasks assigned to the worker node 300. The total number N of tasks is determined and fixed by the master node 200 in step S103.

2) Dynamic-maxStart1: X, which is the number of simultaneously executable GPU tasks, is set to a maximum value according to Equation (3) below, and Y is set to a value obtained according to Equation (2).

Here, Total GPUmem represents the total memory capacity of the GPU 311, and MapTaskmem represents the amount of memory required by one task (map task).

If the value of X is greater than the optimal value, then the value of X is reduced by the dynamic scheduler 353 and the value of Y is increased to converge to the highest value. Likewise, when the value of X is smaller than the maximum value, it is increased by the dynamic scheduler 353 and converged to the highest value.

3) Dynamic-maxStart2: X value is set same as Dynamic-maxStart1. However, the value of Y is set to 0 without following equation (2), and the value of Y increases as the value of X subsequently decreases. This allocation policy has performance similar to that of the GPU 311 alone but does not fully utilize the potential of the hybrid execution of the CPU 309 and the GPU 311. [

4) Dynamic-conservative: Instead of setting X to the maximum value, X is set to the minimum value satisfying Equation 4 and dynamically increased.

The GPU usage rate does not increase in proportion to X but becomes non-linearly saturated, and the X value according to Equation (4) increases in real time and the Y value decreases.

The value of X is determined according to one of the above-mentioned various allocation policies (preferably 2) or 3)), and the determined X value is initialized in step S107 to the maximum number of concurrent operations.

As can be seen from the above various assignment policies, the maximum number of concurrent tasks that can be performed simultaneously in the GPU 311 is the total number N of tasks assigned to the worker node 300 and the number of tasks (CPU usage rate and / or GPU usage rate) of the task to be allocated to the task.

In the initialization process (S107) of the various variables, the (dynamic scheduler 353 of) the node manager 350 sets a specified threshold value (upper in Fig. 6) for comparing the GPU utilization rates. Also, the node manager 350 initializes the task execution current variable (cur_gpu in FIG. 6) being executed in the GPU 311 to zero.

After setting the maximum number of simultaneous execution, the node manager 350 (the dynamic scheduler 353 of the node manager) sets the maximum number of concurrently executed concurrently to the number of concurrently executed desired number variable (desired in FIG. 6).

This concurrent execution desired number can be set on the FSM and can be set in the initial state (EMPTY in FIG. 6). The desired number of simultaneous execution is set to the maximum number of simultaneous execution determined according to the initial allocation policy, but thereafter it is changed in conjunction with the GPU usage rate.

After initialization of various variables, the node manager 350 monitors (S109) the task assignment from the master node 200 (via the application master).

If a new task is input (allocated) via the master node 200, the node manager 350 determines whether the load imbalance state between the CPU 309 and the GPU can be caused (S111).

For example, the node manager 350 judges that the number of already allocated tasks (splits) exceeds the set threshold value, or when it satisfies the expression (1), it may cause load imbalance, and the execution of steps S113 to S117 The process proceeds to step S119 without performing the process.

The node manager 350 recognizing the load unbalance state forcibly assigns the currently assigned task to the GPU 311 (second processing unit) (S119). The execution of the FSM that implements steps S113 and S117 may be interrupted without performing the steps S113 to S117 according to the forced allocation.

In this manner, the node manager 350 forcibly allocates the task assigned to the GPU 311 based on the number of tasks already performed in the worker node 300.

The node manager 350 notifies the CPU 309 (the first processing unit) or the GPU 311 (the second processing unit 311) of the currently input task via the master node 200, if it determines that load imbalance is not caused (S113) based on the number of simultaneous execution of the GPU 311.

For example, the dynamic scheduler 353 of the node manager 350 has an FSM for assigning a new task to the CPU 309 or the GPU 311, which is triggered according to an event related to the task, (For example, 100 mSec). An event related to a task may be an assignment event of a new task or an execution completion event of an assigned task.

Step S113 can be controlled and executed by the FSM and further can be controlled and executed by the FSM also in step S117.

6) of the dynamic scheduler 353, the FSM transitions to the EMPTY state according to the initialization, and initializes various variables at the transition to the EMPTY state or in the EMPTY state (S107). For example, when entering the EMPTY state, the maximum number of simultaneous execution, the desired number of simultaneous execution, and the current number of task execution can be initialized to the set values.

The dynamic scheduler 353 allocates a new allocation task in the EMPTY state to the GPU 311 instead of the CPU 309 and updates the task execution current number of tasks currently executing simultaneously in the GPU 311 (E.g., increments by 1). Following the update (1 increment), the current number of task execution is compared with the maximum concurrent execution number or the concurrent execution number, and if the current number of task execution is greater than or equal to this variable, transition to state TRANSITION1. At the transition to the TRANSITION1 state, the desired number of simultaneous execution may be set to the maximum number of simultaneous execution as shown in FIG.

The TRANSITION1 state is a temporary state in which a new task can not be allocated to the GPU 311 (avail = false). In the state where avail = false, the dynamic scheduler 353 can assign a new task to the CPU 309. [

The GPU usage rate (avg_util) is periodically monitored by the GPU monitor 351 and monitored (S115) after the allocation to the CPU 309 or the GPU 311. [

In the TRANSITION1 state, when the GPU utilization exceeds the set upper limit (the TRANSITION1 state may exist in consideration of the time difference between the GPU task allocation and the subsequent GPU utilization monitoring), the FSM transits the state to the FULL state. In the FULL state, avail is set to false, and newly assigned tasks are all allocated to the CPU 309 by the dynamic scheduler 353. [

Here, when the task assigned to the GPU 311 is completed in each state, the current task execution number of the GPU 311 is decremented by one.

If the GPU usage rate falls below the set threshold value (avg_util <= upper) due to the task unassignment from the FULL state to the GPU 311, the FSM of the dynamic scheduler 353 changes the current desired simultaneous execution count (S117).

For example, in the FULL state, the dynamic scheduler 353 no longer allocates a new task to the GPU 311, but the current number of tasks is reduced by 1 as a task assigned to the GPU 311 is completed Continuously updated.

In the FULL state, when the GPU usage rate falls below the set threshold value, the currently set simultaneous execution number of the FSM of the dynamic scheduler 353 is changed to the sum of the number (for example, 1) 6 set desired = cur_gpu + 1) and transitions to TRANSITION2 state.

Due to the transition from the FULL state to the TRANSITION2 state, the dynamic scheduler 353 can allocate the GPU task again, thereby dynamically changing the desired simultaneous execution count. The worker node 300 can utilize the maximum performance of the GPU 311 through adaptation of the desired number of dynamic concurrent operations.

The desired number of simultaneous changes to be performed is set to a value obtained by adding 1 to the current number of simultaneously executed tasks, which is at least 1 greater than the current number of task execution when the GPU utilization rate is less than or equal to the upper limit value (threshold value) Value.

One or more GPU tasks can be allocated to the desired number of simultaneous operations when the number of the GPUs falls below the threshold immediately after the full state, thereby maximizing the performance of the GPU.

In the TRANSITION2 state, the GPU task can be assigned and transition can be made to the UNDER state or the TRANSITION1 state according to the current number of task execution.

Thus, the FSM is configured to at least initialize the variable and perform steps S113 and S117.

The node manager 350 periodically monitors the GPU usage rate through the GPU monitor 351 and the dynamic scheduler 353 triggers the FSM according to a new task assignment, an end of the assigned task, or a specified period, 309) or the GPU 311, as shown in FIG.

Steps S109 to S119 are repeated a plurality of times in accordance with the assignment of the new task.

It will be apparent to those skilled in the art that various modifications and variations can be made in the present invention without departing from the spirit or scope of the invention. The present invention is not limited to the drawings.

10: Node
100: client node 200: master node
300: Worker node
301: Communication interface 303: Memory
305: mass storage medium 307: system bus / control bus
309: CPU 309-1: CPU core
311: GPU 311-1: GPU Core
350: Node Manager 351: GPU Monitor
353: Dynamic scheduler
370: Task

Claims (14)

A task scheduling method considering heterogeneous processing types,
(b) a first processing unit or a second processing unit based on the number of concurrently executed tasks, the worker node being set by the master node to indicate the number of tasks assigned to the worker node to be performed simultaneously in the second processing unit Dynamically allocating to the processing unit;
(c) the worker node monitoring utilization of the second processing unit; And
(d) the worker node changing the desired number of concurrent operations based on a comparison of the utilization rate and a specified threshold value.
Task Scheduling Method. The method according to claim 1,
Further comprising: before step (b), setting a concurrent maximum number of tasks for which the worker node is to be set for the second processing unit to a concurrent execution number of wishes,
Wherein the step (b) updates the current number of tasks performed in the second processing unit according to task assignment,
Task Scheduling Method. 3. The method of claim 2,
Wherein the step (d) changes the desired number of simultaneous execution to the sum of the numbers specified in the task execution current number when the utilization rate is equal to or larger than the specified threshold,
Task Scheduling Method. 3. The method of claim 2,
Further comprising: setting a maximum number of simultaneous operations by a worker node before the simultaneous execution number setting step,
Wherein the maximum concurrent number of the second processing units is set based on a total number of tasks assigned to the worker node and a usage rate of a first processing unit of a task to be assigned to the second processing unit,
Task Scheduling Method. The method according to claim 1,
Wherein the steps (b) and (d) comprise a finite state machine (FSM) in a dynamic scheduler on a node manager implemented in a worker node,
Wherein the FSM is triggered according to an event associated with the task to be assigned,
Task Scheduling Method. 6. The method of claim 5,
Wherein the steps (b) to (d) are performed a plurality of times,
Prior to step (b), the master node assigning one or more tasks to the worker node; And forcibly assigning the currently assigned task to the second processing unit based on the number of tasks for which the worker node has already been performed,
The FSM implementing step (b) and step (d), if forced to the second processing unit,
Task Scheduling Method. The method according to claim 1,
Wherein the first processing unit is a CPU including a plurality of CPU cores,
Wherein the second processing unit is a GPU comprising a plurality of GPU cores,
Task Scheduling Method. As a distributed processing system considering heterogeneous processing types,
At least one worker node for processing a task,
Each worker node,
A CPU including a plurality of CPU cores; A GPU including a plurality of GPU cores; And
Dynamically assigning a task performed by the CPU or the GPU and assigned to the worker node by a master node to a CPU or a GPU based on the number of concurrently executed tasks set to indicate the number of tasks that can be performed simultaneously in the GPU A node manager,
Wherein the node manager changes the number of simultaneous execution attempts to be used for task assignment to the GPU based on a comparison of the usage rate of the GPU with a specified threshold,
Distributed processing system. 9. The method of claim 8,
The node manager,
A GPU monitor that monitors the utilization of the GPU, and
A dynamic scheduler for assigning a task assigned to a CPU or a GPU based on a desired number of simultaneous execution in the GPU and a utilization rate of the GPU,
Distributed processing system. 10. The method of claim 9,
Wherein the dynamic scheduler sets the maximum number of simultaneously-executed tasks to be set for the GPU as the desired simultaneous execution number and updates the current number of tasks to be performed in the current GPU according to the task assignment,
Distributed processing system. 11. The method of claim 10,
Wherein the dynamic scheduler changes the desired number of simultaneous execution to the sum of the numbers specified in the task execution current number when the usage rate of the GPU is equal to or greater than the specified threshold,
Distributed processing system. 11. The method of claim 10,
Wherein the dynamic scheduler first sets the maximum number of concurrent operations before setting a desired number of simultaneous operations,
Wherein the maximum number of concurrent tasks to be set is set based on a total number of tasks assigned to the worker node and a usage rate of a CPU of a task to be allocated to the GPU.
Distributed processing system. 10. The method of claim 9,
The dynamic scheduler includes an FSM for assigning tasks to a CPU or a GPU,
Wherein the FSM is triggered according to an event associated with the task to be assigned,
Distributed processing system. 14. The method of claim 13,
Further comprising: a master node determining a task to process an input job and assigning the determined one or more tasks to the at least one worker node via a communication network,
Wherein the node manager of the worker node forcibly assigns a currently assigned task to the GPU based on the number of tasks already performed,
Distributed processing system.

Images