Data processing method and apparatus, and vehicle

Abstract

Provided in the present application are a data processing method and apparatus, and a vehicle. The data processing method can be applied to the field of intelligent driving. The method comprises: when tasks of an autonomous driving application are scheduled on computing resources, collecting first resource occupancy information of one or more functions in the autonomous driving application; on the basis of the first resource occupancy information, determining a first resource occupancy model of the autonomous driving application; and on the basis of the first resource occupancy model, configuring the computing resources. The present application can be applied to intelligent vehicles or electric vehicles, helps to avoid computing resource surges and stuttering, and also facilitates a reduction in task latency.

Description

Data processing methods, devices and vehicles

[0001] This application claims priority to Chinese Patent Application No. 202410672148.3, filed on May 27, 2024, entitled "Data Processing Method, Apparatus and Vehicle", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of intelligent driving, and more specifically, to a data processing method, apparatus, and vehicle. Background Technology

[0003] In recent years, with the rapid development of autonomous driving algorithms and technologies, a large number of traditional automakers and emerging autonomous driving companies have entered the market to develop high-level fully autonomous driving systems and applications. Traditional in-vehicle infotainment applications are basically developed using the Automotive Open System Architecture Classic Platform (AUTOSAR CP). Its resource consumption (e.g., central processing unit (CPU) affinity configuration) is modeled during the architecture design phase to ensure that software component (SWC) tasks are isolated from each other and reduce mutual interference.

[0004] Unlike AUTOSAR CP applications, which have fixed functions, low resource usage, and a limited number, current autonomous driving applications are far more complex than in-vehicle infotainment applications in terms of functional logic, resource consumption, and overall number. From a development perspective, autonomous driving applications can be developed based on rich operating systems (OS) such as Linux, or on the automotive open system architecture adaptive platform (AUTOSAR AP). Most of these applications have numerous different functions and complex processing logic, resulting in vastly different consumption of computing resources. Original equipment manufacturers (OEMs) find it difficult to accurately estimate the resource consumption of each Tier 1 supplier's applications during the early design phase. Because the computing resources of autonomous driving hardware platforms are limited, placing applications with high resource preemption on the same computing unit (such as a CPU core) can easily lead to CPU spikes, stuttering, and increased task latency. Summary of the Invention

[0005] This application provides a data processing method, apparatus, and vehicle that helps avoid computational resource overload and lag, and also helps reduce task latency.

[0006] In a first aspect, a data processing method is provided, comprising: when a task of an autonomous driving application is scheduled on computing resources, collecting first resource occupancy information of one or more functions in the autonomous driving application; determining a first resource occupancy model of the autonomous driving application based on the first resource occupancy information; and configuring the computing resources based on the first resource occupancy model.

[0007] Based on the above technical solution, since the resource usage information at the function level is collected, the accuracy of the resource usage model can be guaranteed to be high, which helps to improve the rationality of computing resource allocation, thereby helping to avoid computing resource spikes and lag, and also helps to reduce task latency.

[0008] Furthermore, this application requires no pre-configuration information or test scripts and cases. Users can seamlessly integrate the autonomous driving application into the OS to automatically configure computing resources (e.g., CPU core binding configuration).

[0009] In some possible implementations, the computing resources include one or more of the following: CPU, graphics processing unit (GPU), double data rate (DDR) bandwidth resources, input / output (IO) resources, memory resources, network interface card (NIC) resources, and storage resources.

[0010] In some possible implementations, the first resource occupancy information includes the utilization rate of computing resources by one or more functions.

[0011] In some possible implementations, the first resource occupancy model can be used to determine computing resource configuration information for configuring computing resources.

[0012] For example, by inputting the model's input information into the computing resource occupancy model and setting corresponding constraints for the computing resource occupancy model, the computing resource model can output corresponding computing resource configuration information.

[0013] In the above autonomous driving applications, a process can include one or more threads. A thread can be understood as an entity that executes a function, and a thread is the unit of scheduling.

[0014] In some possible implementations, the method also includes sending a first computing resource occupancy model to a cloud server.

[0015] In this way, the cloud server can store the computing resource usage models sent by multiple vehicles in a computing resource usage model database. The cloud server can then aggregate computing resource usage models uploaded by different vehicle models, different autonomous driving software versions, and different autonomous vehicles within this database, merging and updating them to form various differentiated computing resource usage models. The solver in the cloud server can periodically use the constructed computing resource usage models to obtain computing resource configuration information (e.g., CPU affinity configuration) and update it in the over-the-air (OTA) version, sending it to each vehicle.

[0016] In conjunction with the first aspect, in some implementations of the first aspect, the collection of first resource occupancy information of one or more threads in the autonomous driving application includes: collecting the first resource occupancy information according to random time intervals.

[0017] Based on the above technical solution, by adopting the random walk approach in the data collection process, a fine-grained computing resource usage model can be updated with low overhead. That is, the overhead is minimized as much as possible when updating the computing resource usage model, thereby ensuring a trade-off between the accuracy of the computing resource usage model and the overhead in obtaining the computing resource usage model, which helps to ensure a low-overhead, high-accuracy computing resource usage model.

[0018] In conjunction with the first aspect, in some implementations of the first aspect, before collecting the first resource occupancy information according to a random time interval, the method further includes: collecting the second resource occupancy information of one or more functions according to a preset time interval, the preset time interval being greater than the random time interval; determining the second resource occupancy model of the autonomous driving application based on the second resource occupancy information; wherein, determining the first resource occupancy model of the autonomous driving application based on the first resource occupancy information includes: updating the second resource occupancy model based on the first resource occupancy information to obtain the first resource occupancy model.

[0019] Based on the above technical solution, the resource occupancy information collected based on the random walk idea can be used to update the coarse-grained resource occupancy model to obtain a fine-grained resource occupancy model. This can ensure that the updated resource occupancy model has high accuracy and help improve the rationality of computing resource allocation.

[0020] In some possible implementations, before collecting the second resource occupancy information of one or more functions according to a preset time interval, the method further includes: determining that the computing resource corresponding to the second computing resource occupancy information is the computing resource to be measured for the first time.

[0021] In conjunction with the first aspect, in some implementations of the first aspect, before collecting the first resource usage information of one or more threads in the autonomous driving application according to a random time interval, the method further includes: performing stub processing on the one or more functions; wherein, collecting the first resource usage information of one or more threads in the autonomous driving application according to a random time interval includes: collecting the resource usage information of the one or more functions after aligning the timing information of the one or more functions entering and exiting the stub with the random time interval.

[0022] Based on the above technical solution, resource occupancy information of functions is acquired using a piling technique. After aligning the timing information of function entry and exit from piling points with the timing information of computational resources, the resource occupancy information of the functions is collected. In this way, by aligning the timing information of piling point data with the timing information of computational resources, the collected function-level resource occupancy information can be more accurate (because the time of function entry and exit from piling points is considered, resource occupancy information is only collected when the function enters a piling point, avoiding continued collection of resource occupancy information when the function exits).

[0023] In some possible implementations, stubbing is performed on one or more functions, including: using the Uprobe dynamic stub technique to stub one or more functions.

[0024] In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: visualizing the first resource occupancy information onto the code.

[0025] Based on the above technical solution, the collected function-level resource usage information can be visualized on the code, providing developers with brand-new function-level resource usage information and helping them discover code with unreasonable resource usage.

[0026] For example, when a function experiences high DDR bandwidth resource utilization in the short term, developers can optimize the memory access order or modify the data structure.

[0027] In conjunction with the first aspect, in some implementations of the first aspect, configuring the computing resource according to the first computing resource occupancy model includes: inputting the model's input information into the first computing resource occupancy model to obtain the computing resource configuration information; configuring the computing resource according to the computing resource configuration information; wherein the model's input information includes one or more of the following: the equivalent single-core CPU occupancy rate and probability of occurrence of each thread in the autonomous driving application at different unit time intervals; the average double-rate DDR bandwidth occupancy rate and probability of occurrence of each thread at different unit time intervals; or, the process identifier and overall CPU threshold value within each control group (Cgroup) configuration group.

[0028] Based on the above technical solution, by combining the input information of the above model, the accuracy of the computing resource allocation information input to the computing resource occupancy model can be improved.

[0029] In conjunction with the first aspect, in some implementations of the first aspect, the constraints corresponding to the first computing resource occupancy model include one or more of the following: single-core CPU satisfiability constraints under a completely fair scheduler (CFS) and load balancing; the duration of single-core CPU peaking is less than a preset duration; threshold constraints on the average CPU utilization rate of bound cores and Cgroups; the number of bound cores for all processes of the autonomous driving application is less than or equal to the number of bound cores in the Cgroup; and the sum of CPU utilization rates of all processes in the Cgroup is less than a preset utilization rate.

[0030] Based on the above technical solution, by setting the above constraints on the computing resource occupancy model, the rationality of the computing resource allocation information input into the computing resource occupancy model can be improved.

[0031] In this application, the CPU affinity problem of autonomous driving applications is formalized into a mixed integer linear programming problem with process and thread affinity as variables. The computational resource occupancy model of processes and threads, such as CPU and DDR bandwidth, is mathematically formalized and constraints are constructed. The optimization objective is to reduce the impact of resource contention between services. Its feasible solution may include CPU affinity configuration.

[0032] Secondly, this application provides a data processing apparatus, comprising: a data acquisition unit, configured to acquire first resource occupancy information of one or more functions in an autonomous driving application when the task of the autonomous driving application is scheduled on computing resources; a determination unit, configured to determine a first resource occupancy model of the autonomous driving application based on the first resource occupancy information; and a resource configuration unit, configured to configure the computing resources based on the first resource occupancy model.

[0033] In conjunction with the second aspect, in some implementations of the second aspect, the data acquisition unit is specifically used to: acquire the first resource occupancy information according to random time intervals.

[0034] In conjunction with the second aspect, in some implementations of the second aspect, the data acquisition unit is further configured to: before acquiring the first resource occupancy information according to the random time interval, acquire the second resource occupancy information of one or more functions according to a preset time interval, wherein the preset time interval is greater than the random sampling interval; the determining unit is configured to determine the second resource occupancy model of the autonomous driving application according to the second resource occupancy information; and update the second resource occupancy model according to the first resource occupancy information to obtain the first resource occupancy model.

[0035] In conjunction with the second aspect, in some implementations of the second aspect, the device further includes: a function stub unit, used to perform stubling processing on one or more functions before collecting the first resource occupancy information of one or more threads in the autonomous driving application according to the random time interval; and the data acquisition unit, specifically used to: collect the first resource occupancy information of one or more functions after aligning the timing information of the entry and exit of the one or more functions with the random time interval.

[0036] In conjunction with the second aspect, in some implementations of the second aspect, the apparatus further includes a visualization unit for visualizing the first resource occupancy information onto code.

[0037] In conjunction with the second aspect, in some implementations of the second aspect, the resource configuration unit is specifically used for: inputting the model's input information into the first computing resource occupancy model to obtain the computing resource configuration information; configuring the computing resource according to the computing resource configuration information; wherein, the model's input information includes one or more of the following: the equivalent single-core CPU occupancy rate and probability of occurrence of each thread in the autonomous driving application at different unit times; the average double-rate DDR bandwidth occupancy rate and probability of occurrence of each thread at different unit times; or, the process identifier and overall CPU threshold value within each control group (Cgroup) configuration group.

[0038] In conjunction with the second aspect, in some implementations of the second aspect, the constraints corresponding to the first computing resource occupancy model include one or more of the following: single-core CPU satisfiability constraints under Completely Fair Scheduler (CFS) and load balancing; the duration of single-core CPU peaking is less than a preset duration; threshold constraints on the average CPU utilization rate of bound cores and Cgroups; the number of bound cores for all processes of the autonomous driving application is less than or equal to the number of bound cores in the Cgroup; and the sum of CPU utilization rates of all processes in the Cgroup is less than a preset utilization rate.

[0039] Thirdly, this application provides a data processing apparatus including a processor and a memory, wherein the memory is used to store instructions, and the processor executes the instructions stored in the memory to cause the apparatus to perform any of the possible methods in the first aspect.

[0040] Fourthly, this application provides a data processing system, which includes hardware resources and the apparatus described in the second or third aspect above.

[0041] Fifthly, this application provides a vehicle that includes any of the possible devices of the second or third aspect, or includes the system of the fourth aspect.

[0042] Sixthly, this application provides a computer program product comprising: computer program code, which, when run on a computer, causes the computer to perform any of the possible methods described in the first aspect above.

[0043] It should be noted that the above-mentioned computer program code can be stored in whole or in part on the first storage medium, wherein the first storage medium can be packaged together with the processor or packaged separately from the processor. This application embodiment does not specifically limit this.

[0044] In a seventh aspect, this application provides a computer-readable storage medium storing program code that, when executed on a computer, causes the computer to perform any of the possible methods described in the first aspect above.

[0045] Eighthly, this application provides a chip system including circuitry for performing any of the possible methods described in the first aspect above. Attached Figure Description

[0046] Figure 1 is a schematic diagram of the system architecture provided in an embodiment of this application.

[0047] Figure 2 is another schematic diagram of the system architecture provided in the embodiments of this application.

[0048] Figure 3 is a schematic flowchart of the data processing method provided in the embodiments of this application.

[0049] Figure 4 is another schematic flowchart of the data processing method provided in the embodiments of this application.

[0050] Figure 5 is a schematic diagram of the high-precision acquisition process of the DDR bandwidth resource occupancy model provided in the embodiments of this application.

[0051] Figure 6 is a simplified function-level resource occupancy model alignment diagram provided in the embodiments of this application.

[0052] Figure 7 is another schematic flowchart of the data processing method provided in the embodiments of this application.

[0053] Figure 8 is a schematic block diagram of the data processing apparatus provided in an embodiment of this application. Detailed Implementation

[0054] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; "and / or" in this document is merely a description of the association relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. "At least one" refers to one or more. For example, "at least one of A and B," similar to "A and / or B," describes the association relationship between related objects, indicating that three relationships can exist. For example, at least one of A and B can represent: A existing alone, A and B existing simultaneously, and B existing alone.

[0055] The prefixes such as "first" and "second" used in this application embodiment are merely for distinguishing different descriptive objects and do not limit the position, order, priority, quantity, or content of the described objects. The use of ordinal numbers and other prefixes used to distinguish descriptive objects in this application embodiment does not constitute a limitation on the described objects. The description of the described objects is given in the claims or the context of the embodiments, and should not constitute unnecessary restrictions due to the use of such prefixes. Furthermore, in the description of this embodiment, unless otherwise stated, "multiple" means two or more.

[0056] For example, Figure 1 shows a schematic diagram of the system architecture provided in an embodiment of this application.

[0057] The system architecture includes a vehicle 100 and a cloud server 200. The vehicle 100 includes an autonomous driving application 110, a computing resource model building and optimization device 120, an autonomous driving software platform 130, and an autonomous driving hardware platform 140. The autonomous driving application 110 includes one or more applications related to autonomous driving. The computing resource model building and optimization device 120 includes a computing resource acquisition and update module 121 and a mixed-integer linear programming (MILP) solution and deployment module 122. The autonomous driving software platform 130 includes autonomous driving middleware 131 and an autonomous driving OS 132. The autonomous driving hardware platform 140 includes a CPU 141, a GPU 142, memory 143, a network card 144, storage 145, and DDR bandwidth, etc. The cloud server 200 includes a computing resource usage model database 210 and a MILP solver 220.

[0058] The functions of each software and hardware module are described below:

[0059] The computational resource acquisition and update module 121 can be used to acquire thread-level fine-grained computational resource usage information of the autonomous driving system and autonomous driving applications during the autonomous driving process, and generate and update the computational resource usage model. The MILP solving and deployment module 122 can be used to solve the formalized autonomous driving thread affinity configuration MILP problem on the vehicle 100, and deploy the results on the autonomous driving software platform 130 and the autonomous driving hardware platform 140. The computational resource usage model database 210 can be used to record the computational resource usage models uploaded by different autonomous driving vehicles and store them in the cloud server 200 for future fusion, analysis and optimization. The MILP solver 220 can be used to solve the formalized autonomous driving thread affinity configuration MILP problem. The autonomous driving application 110 can be used to calculate the autonomous driving vehicle control signals or commands based on the raw signals and data acquired by the autonomous driving hardware, through algorithms including but not limited to perception, fusion, prediction, planning and control. The autonomous driving OS 132 can be used to abstract and manage the hardware resources of the vehicle 100, and provide resources and services for the autonomous driving application 110.

[0060] CPU 141 and GPU 142 provide the necessary computing resources (or computing power resources) for autonomous driving systems and applications. Memory 143 provides the necessary memory resources for computing in autonomous driving systems and applications. Network interface card 144 provides network communication resources for autonomous driving systems and applications. Storage device 145 provides general-purpose storage resources for autonomous driving systems and applications.

[0061] The computing resource acquisition and update module 121 can obtain information on the resource usage of CPU, memory, double data rate (DDR) bandwidth resources, network cards, etc. required for building and updating the computing resource model from the autonomous driving software platform 130 and the autonomous driving hardware platform 140, and send it to the computing resource usage model database 210 of the cloud server 200.

[0062] The autonomous driving application 110 obtains computing resources such as CPU, GPU, memory, network card, DDR bandwidth, and storage through the autonomous driving OS132.

[0063] For example, Figure 2 shows another schematic diagram of the system architecture provided in an embodiment of this application.

[0064] Compared to the system architecture shown in Figure 1, the system architecture shown in Figure 2 divides the computing resource acquisition and update module 121 and the MILP solving and deployment module 122 into functional parts. For example, the computing resource acquisition and update module 121 can be divided into a computing resource acquisition module 1211 and a computing resource update agent module 1212, and the MILP solving and deployment module 122 can be divided into a MILP solver 1221 and a computing resource allocation module 1222.

[0065] The computing resource acquisition module 1211 can be used to record computing resource usage information of the autonomous driving application 110 when the vehicle is in autonomous driving mode, including the use of computing resources such as CPU, GPU, DDR bandwidth, and network card. The computing resource acquisition module 1211 can acquire information in ways including but not limited to reading the power management unit (PMU) registers of the CPU 141 on the autonomous driving hardware platform 140, or reading procfs, trace events, etc. in the autonomous driving OS 132, or reading log data of the autonomous driving application 110.

[0066] The computing resource update agent module 1212 can update the fine-grained computing resource usage information of the autonomous driving application 110 collected during the autonomous driving process to the local computing resource usage model, and at the same time send the information to the computing resource usage model database 210 so that the information is stored and recorded in the computing resource usage model database 210.

[0067] The MILP solver 1221 can perform calculations on the autonomous driving software platform 130 and the autonomous driving hardware platform 140 at fixed intervals (e.g., every few days or weeks) using an updated computational resource occupancy model to generate the latest computational resource configuration information (e.g., CPU affinity configuration).

[0068] The computing resource allocation module 1222 can deploy the computing resource configuration information obtained by the MILP solver 1221 to the autonomous driving software platform 130 and the autonomous driving hardware platform 140, ensuring that the autonomous driving application process can make good use of computing resources in a timely manner.

[0069] The computational resource occupancy model database 210 stores computational resource occupancy information captured and updated by different autonomous vehicles during operation, thereby obtaining better computational resource occupancy models for different vehicles and road scenarios, and further integrating and analyzing them to obtain a more complete model. The MILP solver 220 is used to calculate more complex CPU affinity problems with higher accuracy requirements, and its data source is the computational resource occupancy model database 210.

[0070] Figure 3 shows a schematic flowchart of a data processing method 300 provided in an embodiment of this application. The method 300 includes:

[0071] S310: Collect the computing resource usage information of each autonomous driving application in the autonomous driving application list and update the computing resource usage information of each autonomous driving application to the computing resource usage model.

[0072] The above S310 can be executed by the computing resource acquisition module 1211 and the computing resource update agent module 1212.

[0073] S320: When a new autonomous driving application appears in the list of autonomous driving applications, start the task of collecting and modeling computing resource usage information to generate a computing resource usage model for the new autonomous driving application.

[0074] The above S320 can be executed by the computing resource acquisition module 1211 and the computing resource update agent module 1212.

[0075] S330 generates a new linear integer programming problem based on the latest computational resource usage model of all tasks on the current system and automatically deploys the CPU affinity configuration at the model level based on the solution results.

[0076] The above S330 can be executed by the MILP solver 1221 and the computing resource allocation module 1222.

[0077] To address the challenges of multi-threaded, non-periodic operation and explosive resource consumption in autonomous driving applications using AUTOSAR APs, it is necessary to construct thread-level, fine-grained models for various computational resource usage scenarios, while minimizing the consumption of system CPU resources. The principles and impacts of existing acquisition methods are described below with reference to Tables 1 and 2.

[0078] For example, Table 1 shows the collected information of the existing CPU resource usage model.

[0079] Table 1

[0080] For example, Table 2 shows the collected information for the existing DDR bandwidth resource usage model.

[0081] Table 2

[0082] As can be seen from Table 2 above, DDR bandwidth has extremely high transient characteristics. Low-frequency acquisition can only obtain the average value, and without a high-precision model, effective optimization is impossible. To obtain a fine-grained model of computational resource usage, long-term high-frequency acquisition is required. However, during high-frequency acquisition, a large number of invalid acquisitions occur, leading to excessive overhead for the entire autonomous driving system.

[0083] Figure 4 shows a schematic flowchart of a data processing method 400 provided in an embodiment of this application. The method 400 includes:

[0084] S401, stubs the scheduling function.

[0085] For example, the scheduling functions of various scheduling classes (such as CFS, RR, etc.) in the autonomous driving OS can be dynamically stubbed, so that the callback function can be entered during task scheduling, thereby enabling the collection of task scheduling data.

[0086] S402, during the autonomous driving process of the vehicle, captures the task switching data of all T threads in process P within a certain period of time, and calculates the running time data of each thread on the CPU.

[0087] For example, the task switching data above can be the time information of functions entering and exiting stubs in each of the T threads.

[0088] For example, by stubbed out function points in various scheduling classes, such as through uprobe / kprobe dynamic stubbed technology, the runtime scheduling model of the autonomous driving application to be collected on the CPU can be obtained. For example, 10 seconds of thread-level scheduling logs can be collected at once (e.g., scheduling events FTrace and per sched log collection in the Linux operating system).

[0089] S403 calculates a fine-grained latency model for thread tasks based on the runtime data of each thread on the CPU.

[0090] Optionally, a fine-grained latency model for each thread is calculated based on the runtime data of each thread on the CPU, including: calculating the fine-grained latency model of the thread task within a preset duration (e.g., 10s) based on the runtime data of each thread on the CPU using a heuristic algorithm or a task splitting algorithm.

[0091] Optionally, the fine-grained latency model for threaded tasks includes, but is not limited to, the running interval, the running time probability model, the response time probability model, and the number of threads.

[0092] S404 modifies the scheduling function after piling to a resource acquisition module, which collects the computing resource usage information when the autonomous driving application's task is scheduled on the CPU.

[0093] When the remaining CPU is allocated to other tasks, it is not necessary to collect relevant computing resource usage information.

[0094] For example, the scheduling function after instrumentation is modified into a resource acquisition module, including: modifying the dynamic instrumentation callback function of the OS scheduling class into a monitoring hook for the computing resource to be measured (e.g., DDR bandwidth resource). Initialization operations such as assigning values ​​to monitoring registers are completed. The initial monitoring period can be N equal parts of the average runtime latency L, resulting in N time intervals, where N is a positive integer.

[0095] S405, determine whether the computing resources to be monitored are being collected for the first time.

[0096] If this is not the first time the computing resources to be monitored are collected, you can execute S406-S407; if this is the first time the computing resources to be monitored are collected, you can execute S408-S409.

[0097] S406, combined with a random walk algorithm, starts at time t0 with a time interval of l0 = rand(0, int(L / N / 2)), and subsequent time intervals are l... i =l i-1 ±rand(0, int(L / N / 2)), l i ∈[0, int(L / N)], collect computing resource usage information in each time interval.

[0098] The computational resource usage information collected in each random time segment can be rasterized according to a fixed fine-grained time slice (e.g., 10µs), and the values ​​are averaged and normalized before being updated to a whole raster.

[0099] S407 continuously normalizes the computing resource usage information collected by random walks on time slices, and updates the normalized computing resource usage information to the original coarse-grained resource usage model to obtain a fine-grained resource usage model.

[0100] For example, continuously updating the computational resource usage information collected by random walks includes: after each random walk collects N=5 data points, the computational resource usage information collected within the random time interval is rasterized on that time slice, and the values ​​are averaged and normalized to each raster. The update method can include, but is not limited to, moving average, long short-term memory (LSTM), gradient descent, etc., to update the original coarse-grained resource usage model, resulting in the latest fine-grained computational resource usage model. Moreover, the shorter the random time interval, the greater the weight (or importance) of the updated model.

[0101] For example, l i =0.5ms and 1 grid is 10us, then in the time interval l i The collected computing resource usage information can be rasterized across 50 grids, with each of these 50 grids having a weight of w1.

[0102] For example, l i+1 = 3ms and 1 grid is 10us, then in the time interval l i+1 The collected computing resource usage information can be rasterized across 300 grids, with each grid having a weight of w2, where w1 is greater than w2.

[0103] Optionally, if the random time interval exceeds int(L / N), the acquisition event can be skipped, which can further reduce acquisition overhead.

[0104] S408 starts at time t0 when the i-th thread is scheduled to the CPU, and reads the monitoring counter of the computing resource to be monitored at each int(L / N) time, and then calculates the computing resource usage information for that equal time interval.

[0105] S409. Based on the collected N sets of computing resource usage information, calculate the coarse-grained computing resource usage model for the i-th thread.

[0106] Optionally, after executing S409, the detection period starts from time t0+L with a period of l0 = rand(0, int(L / N / 2)), and the subsequent time interval is l. i =l i-1 ±rand(0, int(L / N / 2)), l i ∈[0, int(L / N)]. Then, computational resource usage information is collected at each subsequent random time interval.

[0107] For example, Figure 5 is a schematic diagram of the high-precision acquisition process of the DDR bandwidth resource occupancy model provided in the embodiment of this application.

[0108] As shown in Figure 5(a), the original signal is a waveform signal. One acquisition shown in Figure (a) can be understood as acquiring DDR bandwidth resource usage information according to S408 and S409 of method 400 above. Ten acquisitions can be understood as acquiring DDR bandwidth resource usage information according to S406 and S407 of method 400 above.

[0109] As shown in Figure 5(b), the original signal is a waveform signal. One acquisition shown in Figure (b) can be understood as acquiring DDR bandwidth resource usage information according to S408 and S409 of method 400 above. One hundred acquisitions can be understood as acquiring DDR bandwidth resource usage information according to S406 and S407 of method 400 above.

[0110] As can be seen from Figure 5, by drawing on the idea of ​​random walk, the time for collecting information on the usage of computing resources can be reduced within a preset time period, thereby helping to reduce the overhead when collecting information on the usage of function-level resources.

[0111] In this embodiment of the application, after collecting the fine-grained resource usage model, the time-series data of the dynamic function entry and exit points can be further combined. After the time series of the two are aligned, resource usage data at the function code block level can be obtained, providing developers with new function-level resource usage information, helping developers to discover code with unreasonable resource usage, and verifying the optimization effect.

[0112] For example, Figure 6 shows a simplified function-level resource occupancy model alignment diagram provided in an embodiment of this application.

[0113] As shown in Figure 6, first, the OS scheduling trajectory and the timing of computing resource usage collection (e.g., the random time intervals mentioned above) are aligned. This aligns the computing resource usage model with the OS scheduling trajectory. Then, based on the entry and exit times of the stub functions in the scheduling log, function-level resource usage information can be found. Finally, by combining this with the code segments in the IDE, the computing resource usage information is mapped to the corresponding functions. Furthermore, the IDE's visualization methods can be used to visualize the computing resource usage information on the code. Developers can use this information to further assist in optimizing the code performance of autonomous driving applications. For example, if a function experiences high short-term DDR bandwidth usage, it may be necessary to optimize the memory access order or modify the data structure.

[0114] This application also designs and implements a formal method for resource occupancy models for autonomous driving applications. It treats the application CPU affinity configuration as a mixed integer linear programming problem, with constraints on resource satisfiability, including CPU satisfiability after Linux load balancing and fair scheduling, cgroup-level CPU satisfiability, DDR bandwidth contention, etc. The optimization goal is to reduce the impact of resource contention between services.

[0115] For example, the problem can be formalized as follows:

[0116] (1) Problem variables:

[0117] The M processes of the entire system and the N threads within each process are formalized as variables to be optimized.

[0118] (2) Input information of the model:

[0119] ① The number of CPU cores and DDR bandwidth of the autonomous driving software platform and the autonomous driving hardware platform;

[0120] ② The process identifiers and thread identifiers of the autonomous driving software platform and the autonomous driving hardware platform, and the relationship between the two;

[0121] ③ Process parallelism (the maximum number of threads running in parallel at the same time can be obtained from the process CPU resource usage model);

[0122] ④ The average equivalent single-core CPU utilization rate of each process and each thread on the autonomous driving software platform and the autonomous driving hardware platform;

[0123] ⑤ The average equivalent single-core CPU utilization of each thread in different units of time, and the probability of its occurrence;

[0124] ⑥ The average DDR bandwidth utilization of each thread at different time units, and the probability of its occurrence;

[0125] ⑦ Process IDs and overall CPU thresholds in each Cgroup configuration group.

[0126] (3) Optimization objective:

[0127] Reduce the impact of resource contention between services, i.e., the weighted index of CPU peak values ​​and DDR bandwidth peak values.

[0128] (4) Constraints:

[0129] ①Constraints on the parallelism of processes and threads;

[0130] ② To reduce mutual interference, the number of cores bound to all threads within a process should be less than or equal to the degree of parallelism;

[0131] ③ The total number of cores bound to all threads should be less than or equal to the degree of parallelism, and the union of the cores bound to all threads should be equal to the union of the cores bound to the processes;

[0132] ④ Single-core CPU satisfiability constraints under CFS and load balancing;

[0133] ⑤ Based on fair scheduling and load balancing mode, the sum of CPUs of all threads that can run on a single CPU is less than or equal to the threshold (99%).

[0134] ⑥ In single-core peak scenarios, the duration of CPU peak is less than a certain threshold (e.g., 1 second). That is, only fair scheduling is considered, and the sum of CPU times of all threads that can run on a single CPU is converted into a cumulative value per unit time according to a percentage, and the cumulative value must be less than the threshold;

[0135] ⑦ Core binding and average CPU utilization threshold constraints in Cgroup;

[0136] ⑧ All processes bound to a single core cannot exceed the Cgroup core binding limit;

[0137] ⑨ The sum of CPU usage of all processes in all cgroups must be less than the CPU threshold of the cgroup.

[0138] Figure 7 shows a schematic flowchart of a data processing method 700 provided in an embodiment of this application. The method 700 includes:

[0139] S710 collects the first resource occupancy information of one or more functions in the autonomous driving application when the task of the autonomous driving application is scheduled on computing resources.

[0140] For example, computing resources may include one or more of the following: CPU, GPU, DDR bandwidth, I / O resources, memory, storage resources, or network interface card resources.

[0141] For example, the first resource occupancy information includes the utilization rate of computing resources by one or more functions.

[0142] For example, this first resource occupancy model can be used to determine computing resource configuration information. For instance, by inputting the model's input information into the computing resource occupancy model and setting corresponding constraints for the model, the computing resource model can obtain the corresponding computing resource configuration information.

[0143] Optionally, collecting the first resource usage information of one or more threads in the autonomous driving application includes: collecting the first resource usage information at random time intervals.

[0144] For example, collecting the first resource occupancy information at random time intervals includes: collecting the first resource occupancy information through a random walk algorithm.

[0145] For example, the acquisition time for a single computational resource is L (e.g., 100ms). This L can be divided into N (e.g., N = 10) sampling intervals. In the first sampling interval, a random time interval l0 = rand(0, int(L / N / 2)). For example, l0 can be 0.5ms, and the computational resource acquisition module 1211 can acquire resource usage information for one or more functions within this 0.5ms. In the second sampling interval, a random time interval l1 = l0 ± rand(0, int(L / N / 2)). For example, l1 can be 3ms, and the computational resource acquisition module 1211 can acquire resource usage information for one or more functions within this 3ms. Similarly, in the tenth time interval, a random time interval l9 = l8 ± rand(0, int(L / N / 2)). For example, l9 can be 1ms, and the computational resource acquisition module 1211 can acquire resource usage information for one or more functions within this 1ms.

[0146] By collecting initial resource occupancy information at random time intervals, the overhead of updating the computational resource occupancy model can be minimized. This ensures a trade-off between the accuracy of the computational resource occupancy model and the overhead of obtaining it, thus helping to obtain a low-overhead, high-accuracy computational resource occupancy model.

[0147] Optionally, before collecting the first resource occupancy information according to a random time interval, the method 700 further includes: collecting the second resource occupancy information of one or more functions according to a preset time interval, the preset time interval being greater than the random time interval; determining the second resource occupancy model of the autonomous driving application based on the second resource occupancy information; wherein, determining the first resource occupancy model of the autonomous driving application based on the first resource occupancy information includes: updating the second resource occupancy model based on the first resource occupancy information to obtain the first resource occupancy model.

[0148] For example, the acquisition time for a single computational resource sampling session is L (e.g., 100ms). This L can be divided into N (e.g., N=10) sampling intervals. Within the first sampling interval, with a preset time interval of 10ms, the computational resource acquisition module 1211 can collect resource usage information for one or more functions within these 10ms. Similarly, within the tenth time interval, with a preset time interval of 10ms, the computational resource acquisition module 1211 can collect resource usage information for one or more functions within these 10ms. The second resource usage model obtained from the computational resource usage information collected through the preset time intervals can be understood as a coarse-grained computational resource usage model.

[0149] During the next computing resource collection period following the end of the current collection period, computing resource usage information can be collected at random time intervals. By updating this coarse-grained computing resource usage model based on the computing resource usage information collected at random time intervals, a fine-grained computing resource usage model can be obtained.

[0150] Optionally, before collecting the second resource occupancy information of one or more functions according to a preset time interval, the method 700 further includes: determining that the computing resource corresponding to the second computing resource occupancy information is the computing resource to be measured for the first time.

[0151] Optionally, the vehicle can send the updated first computing resource occupancy model to the cloud server 200. The cloud server 200 can store the computing resource occupancy models sent by multiple vehicles in the computing resource occupancy model database 210. The cloud server 200 can aggregate computing resource occupancy models uploaded by different vehicle models, different autonomous driving software versions, and different autonomous driving vehicles in the computing resource occupancy model database, and merge and update them to form autonomous driving resource occupancy models with various differentiated data. The MILP solver can periodically use the constructed autonomous driving resource occupancy model to calculate resource configuration information (e.g., CPU affinity configuration) and update it in the OTA version and send it to each vehicle.

[0152] Optionally, before collecting the first resource usage information of one or more threads in the autonomous driving application according to a random time interval, the method 700 further includes: performing stub processing on the one or more functions; wherein, collecting the first resource usage information of one or more threads in the autonomous driving application according to a random time interval includes: collecting the first resource usage information of the one or more functions after aligning the timing information of the one or more functions entering and exiting the stub with the random time interval.

[0153] For example, as shown in Figure 6, the OS scheduling trajectory and the timing of computing resource usage collection (e.g., the random time intervals mentioned above) can be aligned first, thus aligning the computing resource usage model with the OS scheduling trajectory. Then, based on the entry and exit times of the stub functions in the scheduling log, the first resource usage information, i.e., the function-level resource usage information, can be found.

[0154] Optionally, the method 700 further includes: visualizing the first resource occupancy information onto the code.

[0155] S720, based on the first resource occupancy information, determines the first resource occupancy model for the autonomous driving application.

[0156] For example, the computing resource update agent module 1212 can update the first resource occupancy information collected by the computing resource acquisition module 1211 into the local resource occupancy model (e.g., the second computing resource occupancy model mentioned above) to obtain the first resource occupancy model.

[0157] S730, configure the computing resource according to the first resource occupancy model.

[0158] Optionally, configuring the computing resource according to the first resource occupancy model includes: determining computing resource configuration information according to the first resource occupancy model; and configuring the computing resource according to the computing resource configuration information.

[0159] For example, taking a CPU as a computing resource, the computing resource configuration information can be a CPU affinity configuration. The computing resource allocation module 1222 can configure the CPU according to the CPU affinity configuration.

[0160] Optionally, configuring the computing resources according to the first computing resource occupancy model includes: inputting the model's input information into the first computing resource occupancy model to obtain the computing resource configuration information; configuring the computing resources according to the computing resource configuration information; wherein the model's input information includes one or more of the following: the equivalent single-core CPU occupancy rate and probability of occurrence of each thread in the autonomous driving application at different unit times; the average double-rate DDR bandwidth occupancy rate and probability of occurrence of each thread at different unit times; or, the process identifier and overall CPU threshold value within each control group Cgroup configuration group.

[0161] Optionally, the constraints corresponding to the first computing resource occupancy model include one or more of the following: single-core CPU satisfiability constraints under CFS and load balancing; the duration of single-core CPU peaking is less than a preset duration; threshold constraints on the average CPU occupancy rate and core binding rate within the Cgroup; the number of cores bound to all processes of the autonomous driving application is less than or equal to the number of cores bound to the Cgroup; or, the sum of the CPU occupancy rates of all processes within the Cgroup is less than a preset occupancy rate.

[0162] The technical solutions in this application embodiment can achieve the following effects:

[0163] (1) No pre-configuration information or test scripts are required. Users can simply put the application into the OS and run it without any notice, and the core binding will be automatically adjusted.

[0164] (2) Establish a fine-grained computing resource usage model for autonomous driving applications, and automatically generate the most suitable CPU resource allocation by solving the mathematical model, instead of randomly adjusting it slowly;

[0165] (3) It supports consideration of complex dynamic scheduling algorithms, load balancing, Cgroups, and task binding to multiple cores on Linux, and solves these problems in the formalization of MILP problems;

[0166] (4) The embodiments of this application include the generation of fine-grained models of different computing resources (e.g., CPU, DDR bandwidth, IO, etc.), which, combined with the formalization and solution of MILP problems, can support core-binding optimization for threads with short-term resource bursts.

[0167] (5) In this embodiment of the application, the fine-grained computing resource usage model can be combined with the code development IDE to help developers discover code functions with unreasonable resource usage.

[0168] Figure 8 shows a schematic flowchart of a data processing apparatus 800 provided in an embodiment of this application. The apparatus 800 includes: a data acquisition unit 810, used to acquire first resource occupancy information of one or more functions in an autonomous driving application when the task of the autonomous driving application is scheduled on computing resources; a determination unit 820, used to determine a first resource occupancy model of the autonomous driving application based on the first resource occupancy information; and a resource configuration unit 830, used to configure the computing resources according to the first resource occupancy model.

[0169] Optionally, the data acquisition unit 810 is specifically used to: acquire the first resource occupancy information according to random time intervals.

[0170] Optionally, the data acquisition unit 810 is further configured to: before acquiring the first resource occupancy information according to the random time interval, acquire the second resource occupancy information of one or more functions according to a preset time interval, wherein the preset time interval is greater than the random sampling interval; the determining unit 820 is configured to determine the second resource occupancy model of the autonomous driving application according to the second resource occupancy information; and update the second resource occupancy model according to the first resource occupancy information to obtain the first resource occupancy model.

[0171] Optionally, the device 800 further includes: a function stub unit, used to stub the one or more functions before collecting the first resource usage information of one or more threads in the autonomous driving application according to the random time interval;

[0172] The data acquisition unit 810 is specifically used to: after aligning the timing information of the entry and exit of the one or more functions with the random time interval, acquire the first resource occupancy information of the one or more functions.

[0173] Optionally, the device 800 further includes a visualization unit for visualizing the first resource usage information onto code.

[0174] Optionally, the resource configuration unit 830 is specifically used for: inputting the model's input information into the first computing resource occupancy model to obtain the computing resource configuration information; configuring the computing resource according to the computing resource configuration information; wherein, the model's input information includes one or more of the following: the equivalent single-core CPU utilization rate and probability of occurrence of each thread in the autonomous driving application at different unit times; the average double-rate DDR bandwidth utilization rate and probability of occurrence of each thread at different unit times; or, the process identifier and overall CPU threshold value within each control group Cgroup configuration group.

[0175] Optionally, the constraints corresponding to the first computing resource occupancy model include one or more of the following: single-core CPU satisfiability constraints under Completely Fair Scheduler (CFS) and load balancing; CPU duration during peak single-core CPU usage is less than a preset duration; threshold constraints on the average CPU utilization rate within a Cgroup; the number of bound cores for all processes in the autonomous driving application is less than or equal to the number of bound cores in the Cgroup; or, the sum of CPU utilization rates for all processes within a Cgroup is less than a preset utilization rate.

[0176] The data processing device 800 can be located in the computing resource model construction and optimization device 120, the data acquisition unit 810 can be located in the computing resource acquisition module 1211, the determination unit 820 can be located in the computing resource update agent module 1212, and the resource configuration unit 830 can be located in the computing resource allocation module 1222.

[0177] It should be understood that the division of units in the above device is only a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, the units in the device can be implemented by a processor calling software; for example, the device includes a processor connected to memory, which stores instructions. The processor calls the instructions stored in memory to implement any of the above methods or to implement the functions of each unit in the device. The processor can be, for example, a general-purpose processor, such as a CPU or microprocessor, and the memory can be internal or external to the device. Alternatively, the units in the device can be implemented as hardware circuits. The functions of some or all units can be implemented through the design of the hardware circuits, which can be understood as one or more processors. For example, in one implementation, the hardware circuit is an ASIC, and the functions of some or all units are implemented through the design of the logical relationships between the components within the circuit. In another implementation, the hardware circuit can be implemented using a PLD, such as an FPGA, which can include a large number of logic gates. The connection relationships between the logic gates are configured through configuration files, thereby implementing the functions of some or all units. All units of the above devices can be implemented entirely through processor calling software, or entirely through hardware circuits, or partially through processor calling software with the remaining parts implemented through hardware circuits.

[0178] In this application embodiment, a processor is a circuit with signal processing capabilities. In one implementation, the processor can be a circuit with instruction reading and execution capabilities, such as a CPU, microprocessor, GPU, or DSP. In another implementation, the processor can implement certain functions through the logical relationships of hardware circuits. These logical relationships are fixed or reconfigurable. For example, the processor may be a hardware circuit implemented as an ASIC or PLD, such as an FPGA. In a reconfigurable hardware circuit, the process of the processor loading a configuration document and configuring the hardware circuit can be understood as the processor loading instructions to implement the functions of some or all of the above units. Furthermore, it can also be a hardware circuit designed for artificial intelligence, which can be understood as an ASIC, such as an NPU, TPU, or DPU.

[0179] As can be seen, each unit in the above device can be one or more processors (or processing circuits) configured to implement the above methods, such as: CPU, GPU, NPU, TPU, DPU, microprocessor, DSP, ASIC, FPGA, or a combination of at least two of these processor forms.

[0180] Furthermore, the units in the above devices can be integrated in whole or in part, or they can be implemented independently. In one implementation, these units are integrated together as a System-on-a-Chip (SoC). The SoC may include at least one processor for implementing any of the above methods or implementing the functions of the units in the device. The at least one processor may be of different types, such as CPU and FPGA, CPU and AI processor, CPU and GPU, etc.

[0181] This application also provides a data processing apparatus, which includes a processing unit and a storage unit. The storage unit is used to store instructions, and the processing unit executes the instructions stored in the storage unit to cause the apparatus to perform the methods or steps described in the above embodiments.

[0182] This application embodiment also provides a vehicle, which includes the above-described computing resource model construction and optimization device 120, or the above-described data processing device 800.

[0183] This application also provides a computer program product, which includes computer program code that, when run on a computer, causes the computer to perform the methods described in the above embodiments.

[0184] This application also provides a computer-readable medium storing program code that, when run on a computer, causes the computer to perform the methods described in the above embodiments.

[0185] This application also provides a chip, which includes a circuit for performing the methods described in the above embodiments.

[0186] In implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software. The method disclosed in the embodiments of this application can be directly implemented by a hardware processor, or by a combination of hardware and software modules within the processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, power-on erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, detailed descriptions are omitted here.

[0187] It should be understood that in the embodiments of this application, the memory may include read-only memory and random access memory, and provides instructions and data to the processor.

[0188] It should also be understood that, in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0189] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0190] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0191] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0192] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0193] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0194] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0195] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be covered. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A data processing method, characterized by, The method comprises the following steps: When tasks of an automatic driving application are scheduled on a computing resource, first resource occupation information of one or more functions in the automatic driving application is collected; A first resource occupation model of the automatic driving application is determined according to the first resource occupation information; The computing resource is configured according to the first resource occupation model.

2. The method of claim 1, wherein, The collection of the first resource occupation information of one or more threads in the automatic driving application comprises the following steps: The first resource occupation information is collected according to a random time interval.

3. The method of claim 2, wherein, Before the collection of the first resource occupation information of one or more threads in the automatic driving application according to a random time interval, the method further comprises the following steps: Second resource occupation information of the one or more functions is collected according to a preset time interval, and the preset time interval is greater than the random time interval; A second resource occupation model of the automatic driving application is determined according to the second resource occupation information; The determination of the first resource occupation model of the automatic driving application according to the first resource occupation information comprises the following steps: The second resource occupation model is updated according to the first resource occupation information to obtain the first resource occupation model.

4. The method according to claim 2 or 3, characterized in that, Before the collection of the first resource occupation information of one or more threads in the automatic driving application according to a random time interval, the method further comprises the following steps: The one or more functions are subjected to a stubbing process; The collection of the first resource occupation information of one or more threads in the automatic driving application according to a random time interval comprises the following steps: After the time sequence information of the one or more functions entering and exiting a stub point and the random time interval are aligned, the first resource occupation information of the one or more functions is collected.

5. The method according to any one of claims 1 to 4, characterized in that, The method further comprises the following steps: The first resource occupation information is visualized on code.

6. The method according to any one of claims 1 to 5, characterized in that, The configuration of the computing resource according to the first computing resource occupation model comprises the following steps: Input information of a model is input into the first computing resource occupation model to obtain computing resource configuration information; The computing resource is configured according to the computing resource configuration information; The input information of the model comprises one or more of the following: Equivalent single-core central processing unit (CPU) occupation rates and probabilities of each thread in the automatic driving application in different unit times; Double data rate (DDR) bandwidth occupation rate means and probabilities of each thread in different unit times; or Process identifiers and total CPU threshold values in each control group (Cgroup) configuration group.

7. The method of claim 6, wherein, The constraint conditions corresponding to the first computing resource occupation model comprise one or more of the following: Single-core CPU satisfiability constraints under a completely fair scheduler (CFS) and load balancing; A duration of a single-core CPU surge is less than a preset duration; Cgroup inner bound core and CPU occupation rate mean threshold constraints; The number of bound cores of all processes of the automatic driving application is less than or equal to the number of Cgroup bound cores; or The sum of CPU occupation rates of all processes in a Cgroup is less than a preset occupation rate.

8. A data processing apparatus, characterized by, The method comprises the following steps: The data collection unit is configured to collect first resource occupation information of one or more functions in the automatic driving application when a task of the automatic driving application is scheduled on a computing resource. The determination unit is configured to determine a first resource occupation model of the automatic driving application according to the first resource occupation information. The resource configuration unit is configured to configure the computing resource according to the first resource occupation model.

9. The apparatus of claim 8, wherein, The data collection unit is specifically configured to: collect the first resource occupation information according to a random time interval.

10. The apparatus of claim 9, wherein The data collection unit is further configured to collect second resource occupation information of the one or more functions according to a preset time interval before collecting the first resource occupation information according to the random time interval, the preset time interval being greater than the random time interval. The determination unit is configured to determine a second resource occupation model of the automatic driving application according to the second resource occupation information. The first resource occupation model is obtained by updating the second resource occupation model according to the first resource occupation information.

11. The apparatus of claim 9 or 10, wherein, The apparatus further includes: The function instrumentation unit is configured to instrument the one or more functions before collecting first resource occupation information of one or more threads in the automatic driving application according to the random time interval. The data collection unit is specifically configured to: collect the first resource occupation information of the one or more functions after aligning time sequence information of the one or more functions entering and exiting a stake point and the random time interval.

12. The apparatus of any one of claims 8-11, wherein, The apparatus further includes: The visualization unit is configured to visualize the first resource occupation information to code.

13. The apparatus of any one of claims 8-12, wherein, The resource configuration unit is specifically configured to: input input information of a model into the first computing resource occupation model to obtain computing resource configuration information; configure the computing resource according to the computing resource configuration information; The input information of the model includes one or more of the following: an equivalent single-core central processing unit (CPU) occupation rate and a probability of occurrence of each thread in the automatic driving application in different unit times; a double data rate (DDR) bandwidth occupation rate mean and a probability of occurrence of each thread in different unit times; or a process identifier and a total CPU threshold value in each control group (Cgroup) configuration group.

14. The apparatus of claim 13, wherein, The constraint condition corresponding to the first computing resource occupation model includes one or more of the following: single-core CPU satisfiability constraints under a completely fair scheduler (CFS) and load balancing; a duration of a single-core CPU rush is less than a preset duration; a bound-core and CPU occupation rate mean threshold constraint in a Cgroup; a number of bound cores of all processes of the automatic driving application is less than or equal to a number of Cgroup bound cores; a sum of CPU occupation rates of all processes in a Cgroup is less than a preset occupation rate.

15. A data processing apparatus, characterized by The apparatus further includes: a memory configured to store a computer program. a processor configured to execute a computer program stored in the memory to cause the apparatus to perform the method of any one of claims 1 to 7.

16. A vehicle characterized by comprising: an apparatus comprising any one of claims 8 to 15.

17. A computer-readable storage medium, characterized in that, a computer program product comprising instructions stored thereon for execution by a processor to cause the processor to implement the method of any one of claims 1 to 7.

18. A computer program product, characterised in that, the computer program product comprising computer program code to, when run on a computer, cause the computer to implement the method of any one of claims 1 to 7.

19. A chip, characterized by the chip comprising circuitry configured to perform the method of any one of claims 1 to 7.

Images