KR101541617B1 - Method and apparatus for analyzing application in multicore embedded linux system - Google Patents

Abstract

A method for analyzing an application program for a multi-core embedded Linux system, the method comprising: receiving a path name or a process ID of a predetermined type for searching for a location-based path of a program to be monitored from a user through an execution interface; The API of the program corresponding to the path name is sequentially called according to whether the path name or the process ID is input through the interface, or the resource is monitored for at least one process currently executing in the Linux system And performing resource monitoring on the application program.

Description

[0001] METHOD AND APPARATUS FOR ANALYZING APPLICATION IN MULTICORE EMBEDDED LINUX SYSTEM [0002]

The present invention relates to a multi-core communication processing service, and more particularly, to a multi-core communication processing service capable of analyzing performance characteristics of a Linux application running on a multicore embedded system, The present invention relates to an improved performance technique in terms of reliability.

As the performance of processors for embedded systems increases, the adoption of multi-core processors is becoming common, especially in smartphones and tablets. Users are expected to improve performance through parallel processing by using multicore processors. However, if the applications on the embedded system are not parallelized, it is likely to increase software complexity and increase energy usage of the system. Therefore, in an embedded system based on a multicore processor, it is very important to balance the processing power and energy consumption of a multicore processor.

In the past embedded systems, a single processor system is often used, and most applications for embedded systems do not consider parallel processing. Therefore, existing applications are likely to fail to fully utilize the hardware of multicore embedded systems.

On the other hand, newly developed applications may have been made considering high performance hardware of modern embedded systems such as multicore processor or GPGPU. Depending on the nature of the application, the performance of the application in the system will vary.

However, if the operating system does not know the characteristics of the application, the inefficiency occurs due to the inability to perform the processing suitable for the characteristics, and consequently, performance degradation or high energy consumption may occur.

In a multicore embedded system, an operating system service is required depending on the characteristics of an application. For this purpose, a method for identifying characteristics of an application is required. Currently, there are limited analysis tools available for developing multicore embedded system software.

For example, the traditional resource measurement tool for Linux systems is top-mounted on Linux and its improved htop [1], which can not identify only the utilization rate of CPU core for a specific application, Of the total number of cores. There are other ways to use a hardware debugger using the JTAG interface, which are very expensive and can not be used unless the JTAG interface for debugging is exposed

Accordingly, the present invention is directed to analyzing the characteristics of an application executed on a multicore embedded system. In order to improve the performance and energy efficiency of an application using the results of the analysis tool without operating system modification for compatibility, And to provide an application analysis method and apparatus for the system.

According to an aspect of the present invention, there is provided an application program analysis method for a multi-core embedded Linux system, the method comprising: receiving a path name or a process ID of a predetermined type for searching for a location- And sequentially executing an API of a program corresponding to the path name according to whether a path name or a process ID is input through the execution interface to execute the corresponding program or to execute at least one process currently executed in the Linux system And performing resource monitoring on the application program by performing resource monitoring on the application program.

According to another aspect of the present invention, there is provided an apparatus for analyzing an application program for a multicore embedded Linux system, the apparatus comprising: an execution interface unit for receiving a path name or a process ID of a predetermined type for searching for a location- And an execution interface unit for sequentially executing an API of the program corresponding to the path name according to whether a path name or a process ID is inputted or executing the corresponding program or for executing at least one process currently executed in the Linux system And a control unit for performing resource monitoring and controlling resource monitoring for an application program.

The present invention has improved performance and energy consumption over existing Linux policy through performance analysis tools that can analyze performance characteristics of Linux applications running on multicore embedded systems.

1 is an overall flowchart of an application program analysis method for a multicore embedded Linux system according to an embodiment of the present invention.
FIG. 2 is a graph showing a utilization ratio of each CPU core when a demand governor and a performance governor to which an application program analysis method for a multicore embedded Linux system according to an embodiment of the present invention is applied.
Figure 3a is a table showing the benchmark results in an existing Linux system.
FIG. 3B is a table showing an analysis result of Firefox using the results of the analysis tool of the present invention.
FIG. 4A is a table showing a result of performing a benchmark of a SunSpider when a benchmark is performed based on test results of an analysis tool to which the present invention is applied.
FIG. 4B is a table showing the results of the Firefox benchmark performed when a benchmark is performed based on test results of the analysis tool to which the present invention is applied.
FIG. 5 is a table of cache misses according to the results of the benchmarking performed when the benchmark is performed based on the test results of the analysis tool to which the present invention is applied.
6 is a detailed block diagram of an application program analysis for a multicore Embedded Linux system in accordance with an embodiment of the present invention.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. It will be appreciated that those skilled in the art will readily observe that certain changes in form and detail may be made therein without departing from the spirit and scope of the present invention as defined by the appended claims. To those of ordinary skill in the art.

The present invention relates to a multicore communication processing service, and more particularly, to a multicore communication processing service which receives a path name or a process ID for searching for a location-based path of a program to be monitored and executes a program corresponding to the path name, And determines whether or not it is suitability according to a predetermined period according to the characteristics of each resource information item to perform grouping. In accordance with rules for monitoring supported by the Linux system, Performance and energy consumption are improved over existing Linux policy through performance analysis tool that can analyze performance characteristics of Linux application running on multicore embedded system by monitoring resource information items for each group Providing technology It wants.

Hereinafter, an application program analysis method for a multicore embedded Linux system according to an embodiment of the present invention will be described in detail.

1 is an overall flowchart of an application program analysis method for a multicore embedded Linux system according to an embodiment of the present invention.

Referring to FIG. 1, in operation 110, an application program specifies an identification value that an operating system module that manages a process under a single process can distinguish by each S / W component of the application program.

In step 112, an execution interface is called. In step 114, it is checked whether or not a predetermined type of path name is input for searching for a location-based path of a program to be monitored by the user through the execution interface.

In this case, the path name is a sequence of alphanumeric symbols for identifying the location of a resource stored on the Linux system, and is a sequence of alphanumeric symbols for identifying the location of a file or a directory. If the path name is specified by a file name, If the file exists in a different directory, a path for searching for the file is specified.

As a result of the check in step 114, if a path name is input, the process moves to step 116 and sequentially calls the API of the program corresponding to the path name. The application programming interface (API) is implemented by calling a function that provides a connection to a specific subroutine for execution in the program. In step 122, the API is called to execute the corresponding program.

These applications are composed of a number of threads in a process, such as a process control block (PCB) data structure (structure) for process / thread management under the Linux operating system. / W Various software components such as platform, 3rd party library, and application can be linked to a single executable file and executed as a single process.

In step 124, in order to perform resource monitoring for the application program corresponding to the path name according to the input of the path name through the execution interface, it is determined whether suitability is determined according to the property of each resource information item.

In step 126, grouping is performed with at least two resource information items, and in step 128, resource information items for each group are monitored according to rules for monitoring supported by the Linux system.

In the case of receiving the path name, the application may be directly executed in a control unit (for example, an application program analysis tool) for controlling application program analysis for the multicore embedded Linux system to which the present invention is applied, and monitoring can be started at the same time. The control unit examines performance characteristics of a program using system information provided by Linux.

The resource monitoring is performed based on policy information corresponding to program-specific execution, and the usage amount of each policy item is accumulated in a data structure for measuring the utilization rate, The predetermined period for each group grouped is applied to the utilization rate measurement for each execution item.

More specifically, the program is generated in units of a first cycle and a jiffy in which monitoring is performed once during program execution for items set as static resource data according to the characteristics of each resource information item A second trigger cycle in which monitoring is performed for each piece of CPU information on the basis of core migration of a thread to be executed, and an item set as task scheduling data, which is a unit in which the program is driven in consideration of the overhead of monitoring by each resource information item A CPU governor / sys / devices / system / cpu / cpu0 / scaling_governor of the system set to the first period after setting a third period in which monitoring is performed in a period defined by the user, Number of cores / sys / devices / system / cpu / possible, 3) monitor the total memory capacity / proc / meminfo data.

/ Proc / [pid] / task / [tid] / stat, the usage time of each core / proc / stat 2) CPU / sys / devices / system / cpu / cpu0 / cpufreq / cpuinfo_cur_freu and 3) Since thread migration occurs on a per-thread basis, examine CPU information per thread. [pid] indicates the PID number of the execution process, and [tid] indicates the TID number of the thread.

1) memory usage / proc / [pid] / task / [tid] / statm, 2) I / O information set in the third cycle; proc / [pid] / task / [tid] / io, network send / receive / proc / self / dev, 3) GPU usage, and 4) other CPU information; / Proc / [pid] / task / sched, the core affinity of the thread / proc / [pid] / task / [tid] / status data. This information is surveyed at intervals of 100 ms or more considering the monitoring overhead in the system as other information.

In addition, the usage amount for each predetermined execution item includes the utilization rate of each core of the program, the GPU usage rate, the memory occupancy rate, and the network transmission / reception amount.

The utilization rate per core is calculated by dividing the cumulative usage amount of each core used for each thread of the process by the predetermined cycle by the total CPU time for the cycle. The / proc file system is a time Is stored in the unit of jig and is used to accumulate the data structure for storing the usage amount per core by reading the information on the CPU time consumed by each thread and the CPU time consumed by each core. In the target system, one thread is set to 10ms to obtain the per-core utilization of the process by dividing the cumulative core usage used by the threads of the process by the total CPU time for that interval at each measurement interval.

At this time, when the process creates a child process, the PID of the parent process, that is, the PPID, is examined and included in the CPU usage. You can find the PPID in the / proc / [pid] / stat file. For this, there is an overhead to retrieve the PPID for a process having a PID number greater than the PID of the process to be analyzed.

The GPU utilization rate is calculated by reading the power on / off state of the GPU from the gpu_power_state variable and converting the power on / off ratio by a predetermined period.

The memory occupancy rate measurement is performed by acquiring information on the amount stored in the memory from the proc file system, accumulating the data in a data structure for memory measurement, accumulating the data in byte units, Divided by the number of processes, and dividing the average of the accumulated amount loaded into the memory by the predetermined interval by the total memory size.

In the network transmission / reception amount measurement, the transmission / reception amount accumulated in the / proc file system is read in units of measurement intervals, and the difference from the previous value is accumulated in the data structure for network usage measurement.

If it is determined in step 114 that the program path name is not input, the flow advances to step 118 to confirm the input of the process ID. In step 120, at least one currently executed process is recognized, Moves to perform subsequent operations.

2, FIG. 2 is a graph illustrating the utilization ratio of each CPU core when a demand governor and a performance governor to which an application program analysis method for a multicore embedded Linux system according to an embodiment of the present invention is applied, Firefox generates about 30 threads, but the maximum number of threads that can be executed simultaneously is three. Therefore, Firefox can not take advantage of all four-core CPUs.

At this time, the table shown in FIG. 3A shows energy consumption and performance when each governor is used. Because performance on the SunSpider benchmark is processing time, the smaller the time, the higher the performance. Thus, energy efficiency is proportional to the product of energy consumption and performance (Joule-second). The required governor has about 5153.3 J ㆍ s and the performance governor has 3347.4 J ㆍ s Joule - second. Therefore, the performance governor shows higher performance than the energy consumed by the performance governor.

The table in FIG. 3B shows the execution of Firefox analyzed by the application analysis tool. The maximum number of threads executed at the same time is 3, but the maximum CPU utilization is actually 100% or less regardless of the frequency. The parallelism of the current version of Firefox is not enough to take advantage of multicore systems. The number of cores in the system is four, but the maximum CPU utilization rate of the system as a whole is less than 100% on the average and 213% or less on the average. Performance governors performing at full speed are not able to take advantage of the entire core. Therefore, this application does not fully utilize the multi-core CPU, and it is expected that the performance will be equivalent even if it is actually performed in one core. Rather, the use of many cores would result in the overhead of core migration and the resulting performance degradation of the cache. Also, as a result of measurement, Firefox for ARM did not use GPU.

Based on this, I performed the SunSpider benchmark test using Firefox with the following settings.

Since the maximum system CPU utilization is 213%, the number of on-line cores is two. The remaining two cores are configured offline using hot-plugging.

Because the application's maximum CPU utilization is less than 100%, Firefox applications do not allow core migration by assigning to CPU1 core fixedly.

The table shown in FIG. 4A shows the result of performing the benchmark of the SunSpider when the benchmark is performed with the above setting. As shown in the table of FIG. 4A, when fixed to one core, higher performance can be obtained with less energy consumption. In the case of using Joule-second, about 4592.6 J ㆍ s when the required governor is used and about 3142.9 J ㆍ s when using the performance governor, respectively, showing about 10.88% and about 6.11%, respectively, .

The table shown in FIG. 4B shows a result of analyzing the benchmark test of Firefox performed in the test in which the analysis result is applied, using the analysis tool.

As shown in FIG. 4B, by freeing the execution core of the program and removing the migration of threads, the CPU utilization of the entire system is lowered and the memory usage is also reduced. In addition, performance improvement due to a decrease in cache miss due to no migration is expected. The actual measurement result is the same as the table shown in FIG.

The cache miss was unable to measure the program-only values, so the values of the entire system were measured. The reason why the cache miss rate is not compared is because the execution time itself is different in the two executions, and the total number of execution commands of the system is different. The cache miss was unable to measure the program-only values, so the values of the entire system were measured. The reason why the cache miss rate is not compared is because the execution time itself is different in the two executions, and the total number of execution commands of the system is different. When comparing the cache misses, it can be seen that the misses of DCache load / store and ICache decreased by 17.85%, 19.12%, and 6.97%, respectively, when the execution core was fixed.

In the foregoing, an application program analysis method for a multicore embedded Linux system according to an embodiment of the present invention has been described with reference to FIG.

Hereinafter, an application program analyzing apparatus for a multi-core embedded Linux system according to an embodiment of the present invention will be described with reference to FIG.

6 is a detailed block diagram of an application program analysis for a multicore Embedded Linux system according to an embodiment of the present invention.

6, the apparatus 600 to which the present invention is applied includes an execution interface unit 610, a system memory 612, a control unit 616, a policy information unit 618, a resource usage calculation unit 620, (622) and a monitoring unit (624).

The execution interface unit 610 receives a path name or a process ID of a predetermined type for searching for a location based path of a program to be monitored by a user.

The system memory 612 can be volatile (such as RAM), nonvolatile (such as ROM, flash memory, etc.), or a combination of the two. The system memory 612 generally includes a drive system 614, one or more program modules, and may include program data.

The control unit 616 sequentially invokes the API of the program corresponding to the path name according to whether the path name or the process ID is inputted through the execution interface unit 610 and executes the corresponding program or executes the corresponding program in the Linux system And performs resource monitoring for at least one process in execution to perform resource monitoring for the application program.

Under the control of the control unit 616, the monitoring unit 624 determines whether or not suitability is determined for each predetermined period according to the characteristics of each resource information item, performs grouping into at least two or more resource information items, Monitoring of resource information items for each group is performed according to the rules for monitoring supported by the system.

Under the control of the control unit 616, the resource usage calculation unit 620 calculates a usage amount for each execution item of the policy information according to the policy information of the policy information unit corresponding to the execution of the program, And a predetermined period for each group grouped according to the characteristics of each resource information item is calculated and applied to the utilization rate of each execution item.

The period setting unit 622 generates a period in a first cycle and a jiffy unit in which monitoring is performed once during program execution for items set as static resource data under the control of the controller 622 In consideration of an overhead of monitoring according to the resource information item and a second trigger cycle in which monitoring is performed for each piece of CPU information on the basis of the core migration of the thread to which the task is scheduled to be executed, And a third period in which monitoring is performed at a period defined by the user.

Here, the first period is set in a resource information item indicating a CPU governor of the system, a number of cores currently available, and a total memory capacity, and the second period is set to a value obtained by multiplying the processor usage of the process, The CPU frequency, and the number of times of context switching, and the third cycle is set in a resource item indicating memory usage, I / O information, GPU usage, and other CPU information.

Then, the resource usage calculation unit 620 calculates a usage rate, a GPU usage rate, a memory occupancy rate, and a network transmission / reception amount for each core of the corresponding program, and the usage rate for each core is calculated by a cumulative core Wherein the GPU usage rate is calculated by reading the GPU power ON / OFF status from the gpu_power_state variable and converting the GPU power ON / OFF status into a percentage for each predetermined period, and the memory occupancy rate is calculated by dividing The proc file system acquires information about the amount of data stored in the memory, adds it to the data structure for memory measurement, accumulates it in byte units, and divides it by the number of processes shared by other application programs And the average of the accumulated amount loaded in the predetermined interval-specific memory is stored in the total memory Size. ≪ / RTI >

As described above, the operation of the method and apparatus for analyzing an application program for a multi-core embedded Linux system according to the present invention can be performed. While the present invention has been described with respect to specific embodiments thereof, Can be carried out without departing from the scope. Accordingly, the scope of the present invention should not be limited by the illustrated embodiments, but should be determined by equivalents of the claims and the claims.

610: execution interface unit 612: system memory
616: Control section 618: Policy information section
620: Resource usage calculation unit 622: Period setting unit
624:

Claims (12)

In an application analysis method for a multicore embedded Linux system,
Receiving a path name or a process ID of a predetermined type for searching for a location based path of a program to be monitored from a user through an execution interface;
A process for executing a corresponding program by sequentially calling an API of a program corresponding to the path name according to whether a path name or a process ID is input through the execution interface or a resource monitoring for at least one process currently running in the Linux system And performing resource monitoring for the application program,
The resource monitoring may include:
According to the characteristics of each resource information item, it is judged whether or not suitability is determined according to a predetermined cycle, and the grouping is performed by at least two or more resource information items. In accordance with rules for monitoring supported by the Linux system, Perform monitoring on the item,
And accumulating the usage amount of each policy item in the data structure for measuring the utilization rate according to the policy information corresponding to the execution of the program and setting a predetermined period for each group grouped according to the property of each resource information item To calculate the usage rate for each execution item,
The predetermined period according to the property of each resource information item,
A first cycle in which monitoring is performed once during program execution for an item set as static resource data,
A second wavelet period in which monitoring is performed per CPU for CPU information based on core migration of a thread occurring in units of jiffy,
And a third period in which monitoring is performed at a period defined by a user for an item set as task scheduling data, which is a unit in which the corresponding program is driven, in consideration of an overhead of monitoring by each resource information item. An application analysis method for a system. delete delete delete The method according to claim 1,
The first period is set in a resource information item indicating a CPU governor of the system, a number of cores currently available and a total memory capacity,
Wherein the second grip period is set in a resource information item indicating a processor use amount of a process, a CPU frequency in a corresponding grip, and a context switching count,
Wherein the third period is set in a resource item indicating memory usage, I / O information, GPU usage, and other CPU information, and monitoring is performed for each resource information item for each cycle, and the application program for the multicore embedded Linux system Analysis method. 2. The method according to claim 1,
GPU usage rate, memory occupancy rate, and network transmission / reception rate of the corresponding program,
The utilization ratio for each core is,
Is calculated by dividing the cumulative usage amount of each core used per thread of the predetermined cycle by the total CPU time for the cycle,
The GPU utilization rate
The power on / off state of the GPU is read from the gpu_power_state variable and accumulated and converted into a percentage by a predetermined period,
Wherein the memory occupancy rate measurement comprises:
The proc file system obtains information about the amount of memory in the memory, adds it to the data structure for memory measurement, accumulates it in bytes, and then divides the memory shared by other applications by the number of shared processes. And dividing an average of the accumulated amount loaded into the memory at a predetermined interval by the total memory size, and analyzing the application program for the multicore embedded Linux system. 1. An application analyzer for multi-core embedded Linux systems,
An execution interface unit that receives a path name or a process ID of a predetermined type for searching for a location-based path of a program to be monitored by a user,
The execution interface unit sequentially calls the API of the program corresponding to the path name according to whether the path name or the process ID is input, and executes the corresponding program, or performs resource monitoring for at least one process currently executing in the Linux system To perform resource monitoring for an application program,
According to the control of the control unit, it is determined whether or not suitability is determined according to the property of each resource information item by the predetermined period, and the grouping is performed by at least two or more resource information items. And a monitoring unit for monitoring the resource information item for each group,
Wherein the control unit accumulates the usage amount of each policy item in the data structure for measuring the utilization rate according to the policy information corresponding to the execution of the program according to the control of the control unit, Further comprising a resource usage calculation unit for calculating a predetermined period of time for each group by applying to the utilization rate of each execution item,
A first period in which monitoring is performed once during program execution for items set as static resource data under the control of the control unit,
A second wavelet period in which monitoring is performed per CPU for CPU information based on core migration of a thread occurring in units of jiffy,
And a period setting unit configured to set a third period in which monitoring is performed at a period defined by the user with respect to items set as task scheduling data that is a unit in which the program is driven in consideration of the overhead of monitoring by each resource information item Application analyzer for multicore embedded Linux systems. delete delete delete 8. The method of claim 7,
The first period is set in a resource information item indicating a CPU governor of the system, a number of cores currently available and a total memory capacity,
Wherein the second grip period is set in a resource information item indicating a processor use amount of a process, a CPU frequency in a corresponding grip, and a context switching count,
Wherein the third cycle is set in a resource item indicating memory usage, I / O information, GPU usage, and other CPU information, and monitoring is performed for each resource information item for each cycle. The multi-core embedded Linux system according to claim 1, Analysis device. 8. The resource allocation method according to claim 7,
GPU usage rate, memory occupancy rate, and network transmission / reception ratio of the corresponding program,
The utilization ratio for each core is,
Is calculated by dividing the cumulative usage amount of each core used per thread of the predetermined cycle by the total CPU time for the cycle,
The GPU utilization rate
The power on / off state of the GPU is read from the gpu_power_state variable and accumulated and converted into a percentage by a predetermined period,
Wherein the memory occupancy rate measurement comprises:
The proc file system obtains information about the amount of memory in the memory, adds it to the data structure for memory measurement, accumulates it in bytes, and then divides the memory shared by other applications by the number of shared processes. And dividing an average of the accumulated amount loaded into the predetermined interval memory by the total memory size.

Images