Method for dynamically adjusting CPU utilization rate of OTA software

Abstract

The invention discloses a method for dynamically adjusting the CPU utilization rate of OTA software. According to the method, a cpulimit control module is added into all threads occupying more CPU resources in an OTAAPP process, operations such as file reading and writing, decryption and hash verification are subjected to block processing, and cpulimit control is implemented in the block processing. The occupancy rate is calculated by obtaining the system time and the process CPU use time, and whether the thread is dormant or not is determined after the occupancy rate is compared with the limit value, so that the CPU use rate is dynamically adjusted. The scheme does not need extra process collaboration, does not depend on an operating system kernel version, can be automatically adjusted according to system resource conditions, realizes non-inductive OTA upgrading, improves user experience, and is suitable for various scenes such as vehicle-mounted equipment and mobile terminals.

Description

Technical Field

[0001] This invention relates to the field of wireless communication technology, specifically to a method for dynamically adjusting the CPU usage of OTA software when remotely updating device software via wireless means (OTA, Over-the-Air), belonging to the intersection of system resource management and wireless communication technology. Background Technology

[0002] Over-the-Air (OTA) is a technology that enables remote updates to device software or firmware via wireless networks, and it is widely used in many fields such as smartphones, smart cars, and IoT devices. With the adoption of A / B partitioning for devices, the concept of "seamless" upgrades is becoming increasingly popular in OTA upgrades. To truly achieve "seamless" upgrades without affecting the user experience, it is crucial to dynamically limit the CPU usage of the OTA software and keep it within a reasonable resource range.

[0003] Currently, there are two main CPU limiting techniques. One is cpulimit, which specifies a fixed value based on signal control. As a user-space tool, it controls the process's running state by alternately sending SIGSTOP and SIGCONT signals to the target process, thus limiting CPU utilization to fluctuate around the target value. While this method is simple and has broad compatibility, it has significant drawbacks: it requires two processes to work together; the main process is responsible for reading the child process's CPU utilization and performing signal control, while the child process handles OTA upgrades; frequent signal operations incur additional context switching overhead; and it lacks adaptive capabilities, failing to automatically adjust the limiting strategy based on overall system CPU utilization, process priority, or business importance.

[0004] The second is the cpulimit control mechanism based on cgroups, which uses a kernel-level fixed value. It leverages the resource management mechanisms provided by the Linux kernel to fine-tune the CPU, memory, and I / O resources of processes or process groups, limiting the CPU time slice allocation for processes. Compared to the traditional signal-based cpulimit, its CPU limiting is more efficient and precise, and it does not introduce additional context switching overhead. However, it also has limitations: it requires a relatively new Linux kernel version (2.6.24 and above), relies on the operating system's CPU subsystem (cpu, cpuacct, cpuset) to limit process CPU resource usage, and may not be usable in some production environments due to the CPU subsystem not being enabled or mounted; when a process suddenly uses CPU in a short period (such as during startup), it may quickly exhaust its quota, resulting in forced rate limiting for the remaining time, affecting response speed; it also lacks adaptive capabilities and cannot automatically adjust the limiting strategy based on factors such as the overall system CPU utilization.

[0005] In summary, existing technologies for limiting CPU usage in OTA software suffer from problems such as complex process coordination, high overhead, dependence on specific kernel versions, and insufficient adaptability, necessitating a better solution. Summary of the Invention

[0006] This paper presents a solution for implementing CPU limit control within the OTA process itself. This solution eliminates the need to launch separate main and child processes, avoiding additional context switching overhead; it is independent of the operating system kernel version and CPU subsystem; and it can dynamically adjust CPU utilization based on system resource usage to achieve seamless OTA upgrades and improve user experience.

[0007] System overall framework: In the OTAAPP process, a cpulimit control module (function) is added to all threads that consume a significant amount of CPU resources. When these threads perform operations such as file reading and writing, hash verification, and decryption, the cpulimit function is called to control the CPU usage of the process itself.

[0008] Solution Process: The OTA program starts and initializes the cpu_limit module.

[0009] The OTA program waits for the user to trigger the task, and then creates a subtask thread.

[0010] In the subtask thread, data operations that consume a lot of CPU resources (such as file reading and writing, data decryption, and hash verification) are processed in blocks, and cpu_limit control is added to the block processing.

[0011] The specific implementation of cpu_limit control is as follows: Call pthread_mutex_lock to protect the cpulimit module and prevent multiple threads from operating on it simultaneously.

[0012] Obtain the CPU limit value cpu_limit_percent from the system CPU resource monitoring module.

[0013] The system calls the Linux system function `gettimeofday` to obtain the current system time `current_time`, subtracts it from the `last_time` recorded by the `cpu_limit` function, and obtains the sampling time `sample_time`. It then checks whether `sample_time` has reached the specified sampling time threshold; if not, it exits the process.

[0014] If the threshold is reached, the Linux system function getrusage is called to obtain the current CPU usage time of the process, current_usage_time (ru_utime + ru_stime).

[0015] Subtract the CPU usage time last_usage_time recorded at the last sampling time from current_usage_time to obtain the actual CPU usage time cpu_usage_time within the two valid sampling time intervals.

[0016] Calculate CPU utilization (cpu_utilization), which is cpu_usage_time divided by sample_time.

[0017] If cpu_utilization does not exceed the limit value cpu_limit_percent (e.g., 5%), then update the last sample time last_time and CPU usage time last_usage_time of the cpu_limit function, and then exit the cpu_limit function.

[0018] If cpu_utilization exceeds the limit value cpu_limit_percent, calculate the thread sleep time sleep_time (in ms). The calculation formula is: sleep_time=((cpu_usage_time / cpu_limit_percent)-sample_time)*1000.

[0019] Calling the Linux system function nanosleep causes the thread to sleep for the time specified by sleep_time.

[0020] Call gettimeofday again to get the current system time current_time and update last_time; call getrusage to get the current CPU usage time and update last_usage_time.

[0021] Call pthread_mutex_unlock to release the lock and exit the cpu_limit function.

[0022] Once the subtask is completed, exit the subthread. Beneficial effects of the present invention Dynamic adjustment of CPU utilization in OTA programs is implemented: when the cpulimit module in the OTA program detects an increase in available CPU resources, it will increase the percentage of CPU time used by the OTA process, significantly accelerating the OTA upgrade speed; when it detects a decrease in available CPU resources, it will decrease the percentage of CPU time used by the OTA process to avoid affecting the normal operation of user software.

[0023] Compared to existing technologies, it requires no additional process coordination, reduces context switching overhead, and is not dependent on a specific kernel version, making it more widely applicable (e.g. Figure 4 The experimental data comparison chart is shown. Attached Figure Description

[0024] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 This is a system framework diagram of a method for dynamically adjusting the CPU utilization of OTA software according to the present invention; Figure 2 This is a flowchart of a method for dynamically adjusting the CPU utilization of OTA software according to the present invention. Figure 3 This is a timing diagram of the control scheme for a method of dynamically adjusting the CPU utilization of OTA software according to the present invention. Figure 4 This is a comparison chart of measured data for a method of dynamically adjusting the CPU usage of OTA software according to the present invention (the left column of data is the measured data of the OTA program's CPU usage set by the system's cpulimit command; the right column of data is the measured data of the OTA program using this solution). Detailed Implementation

[0025] According to an embodiment of the present invention, a method for dynamically adjusting the CPU utilization of OTA software is provided.

[0026] Vehicle-mounted equipment scenario: This CPU limit control scheme is integrated into the OTA upgrade program of a certain vehicle equipment, and an adapter interface is added to the software system so that the CPU_limit module can obtain the CPU utilization rate currently allocated to the OTA program by the system, thereby realizing the dynamic setting of the CPU utilization rate of the OTA program.

[0027] When the in-vehicle device starts up and detects a new version update, the user clicks to install, and the OTA program begins the update. At this time, if the device's CPU resource monitoring module detects that the car speed is 0 and the in-vehicle device's operating software is not yet running, it will notify the cpu_limit module through the adapter interface, causing it to upgrade at a higher CPU utilization rate, thus speeding up the upgrade process.

[0028] Afterwards, the user starts driving the car, and the working software of the in-vehicle device officially runs. At this time, the device's CPU resource monitoring module notifies the cpu_limit module through the adapter interface to reduce the CPU usage of the OTA process to a certain value. The cpu_limit module automatically adjusts to avoid affecting the normal operation of the in-vehicle device's working software.

[0029] Mobile terminal scenarios: This CPU limit control scheme is incorporated into the OTA upgrade program of mobile phones. At the same time, an adapter interface is added to the software system so that the CPU_limit module can obtain the CPU usage currently allocated to the OTA program by the system and realize dynamic setting.

[0030] When the mobile device detects a new version update upon connecting to the internet, the user clicks to install, and the OTA (Over-The-Air) program begins updating in the background. If the device's CPU resource monitoring module detects a low overall CPU load at this time, it will notify the cpu_limit module through the adapter interface, causing it to upgrade with higher CPU utilization.

[0031] During the upgrade process, if users perform operations that result in high CPU usage, such as taking photos and editing videos or playing demanding games, the software system's CPU resource monitoring module will notify the cpu_limit module through the adapter interface to lower the CPU limit to the specified value, ensuring that normal user operations are not affected.

[0032] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for dynamically adjusting the CPU utilization of OTA software, characterized in that, Includes the following steps: Initialize the cpu_limit module in the OTA program; Wait for the user to trigger the task, then create a subtask thread; In the subtask thread, data operations that consume a lot of CPU resources, such as file reading and writing, data decryption, and hash verification, are processed in blocks, and cpu_limit control is added to the block processing. The cpu_limit control specifically includes: locking and protecting the cpulimit module, obtaining the CPU limit value from the system CPU resource monitoring module, obtaining the current system time and calculating the sampling time, determining whether the sampling time has reached the threshold, obtaining the current CPU usage time of the process and calculating the actual usage time and utilization rate after reaching the threshold, deciding whether to let the thread sleep based on the comparison result of the utilization rate and the limit value, updating the time and CPU usage records after sleeping, and finally unlocking.

2. The method according to claim 1, characterized in that, The block processing involves dividing data operations that consume a lot of CPU resources into multiple data blocks and processing them sequentially.

3. The method according to claim 1, characterized in that, To get the current system time, use the Linux system function gettimeofday; to get the current CPU usage time of a process, use the Linux system function getrusage.

4. The method according to claim 1, characterized in that, In the cpu_limit control, when the CPU utilization rate exceeds the limit value, the formula for calculating the thread sleep time is: sleep_time=((cpu_usage_time / cpu_limit_percent)-sample_time)*1000, where sleep_time is in ms.

5. The method according to claim 1, characterized in that, The locking and unlocking are implemented using the pthread_mutex_lock and pthread_mutex_unlock functions, respectively, to protect the cpulimit module in a multi-threaded environment.

6. The method according to claim 1, characterized in that, The method is independent of the operating system kernel version and CPU subsystem, and can be applied in environments such as ordinary Linux systems and Unix-like QNX operating systems.

7. The method according to claim 1, characterized in that, By adding a cpulimit control module to all threads in the OTAAPP process that consume a lot of CPU resources, the CPU utilization of the entire OTA process can be controlled.

Images