Application processing method and apparatus, and electronic device

Abstract

This application provides an application processing method, apparatus, and electronic device. The method includes: determining resource access time-series data of an application within a single runtime cycle; and, based on the resource access time-series data of each application, determining whether the total access volume of all applications to a target resource in each sampling cycle is less than a preset access volume. If the total access volume of the target resource in a target sampling cycle is greater than or equal to the preset access volume, then the design of at least one application is adjusted. The resource access time-series data includes the access volume of the application to the target resource in each sampling cycle contained within the runtime cycle. The application is integrated into a computing device containing a multi-core processor, and the preset access volume is less than or equal to the total available target resource. This method improves resource utilization and overall device performance while ensuring the performance determinism of the application in a resource-contention environment.

Description

Technical Field

[0001] This application relates to the field of avionics technology, and more particularly to an application processing method, apparatus, and electronic device. Background Technology

[0002] Avionics systems include onboard computing devices that allow the integration and execution of third-party developed applications, supporting continuous updates to existing applications or the integration of new ones. However, when multiple applications run on the same onboard computing device, preventing interference between them is a critical issue affecting system security and reliability.

[0003] Currently, the main approach is to limit the excessive use of system resources by each application, under the premise of preset static resource quotas, in order to avoid multi-core interference.

[0004] However, this method suffers from technical problems such as low resource utilization and reduced performance. Summary of the Invention

[0005] This application provides application processing methods, apparatus, and electronic devices to improve resource utilization and performance.

[0006] In a first aspect, embodiments of this application provide an application processing method, including:

[0007] Determine resource access time series data for an application within a single runtime cycle, the resource access time series data including the amount of access to a target resource by the application within each sampling period contained in the runtime cycle, the application being integrated into a computing device containing a multi-core processor;

[0008] Based on the resource access time series data of each application, determine whether the total access volume of all applications to the target resource in each sampling period is less than a preset access volume; wherein, the preset access volume is less than or equal to the total available amount of the target resource;

[0009] If the total number of accesses to the target resource during the target sampling period is greater than or equal to the preset number of accesses, then the design of at least one application will be adjusted.

[0010] In one possible implementation, determining the application's resource access time-series data over a single runtime cycle includes:

[0011] The resource access time series data for each application are determined sequentially in descending order of priority.

[0012] Specifically, when determining the resource access time series data of the current application, applications with higher priority than the current application remain running and trigger a preset maximum resource consumption scenario; the priority of the application is positively correlated with its importance to the system functions of the computing device.

[0013] In one possible implementation, determining the resource access time-series data for each application includes:

[0014] Based on the initial resource access time series data corresponding to multiple operating cycles, the initial resource access time series data is differentially processed to obtain intermediate resource access time series data.

[0015] The resource access time series data is constructed based on the maximum access volume of the application in the same sampling period across multiple runtime cycles.

[0016] In one possible implementation, determining whether the total access volume of all applications to the target resource in each sampling period is less than a preset access volume based on the resource access time series data of each application includes:

[0017] Step a: Determine the current application to be overlaid in descending order of priority;

[0018] Step b: For each sampling period, based on the application's resource access time series data, the access volume of the current application to be superimposed in the sampling period is superimposed with the total access volume of the already superimposed applications in the sampling period to obtain the total access volume of the currently superimposed applications in the sampling period.

[0019] Step c: Determine whether the total access volume of the currently overlaid application in each sampling period is less than the preset access volume;

[0020] Step d: If the total access volume of the target sampling period is greater than or equal to the preset access volume, then determine that the total access volume of all applications in the target sampling period is greater than or equal to the preset access volume;

[0021] Step e: If the total access volume of the currently superimposed application in each sampling period is less than the preset access volume, then repeat steps a to d.

[0022] In one possible implementation, if the total access volume of the target resource during a target sampling period is greater than or equal to the preset access volume, then adjusting the design of at least one application includes:

[0023] If the total access volume of the target resource in the target sampling period is greater than or equal to the preset access volume, then the access action of the at least one application to the target resource in the target sampling period will be delayed to another sampling period, wherein the other sampling period is a sampling period in which the total access volume is less than the preset access volume.

[0024] And / or, reduce the overhead of the at least one application on the target resource during the target sampling period.

[0025] In one possible implementation, prior to determining the application's resource access time-series data over a single runtime cycle, the method further includes:

[0026] Control each master node with resource access capabilities to initiate a maximum resource access request for the target resource;

[0027] When all master nodes are in the state of initiating the maximum resource access request, obtain the maximum access volume of each master node for the target resource;

[0028] The maximum access volume of each master node for the target resource is summed, and the resulting value is determined as the total available amount of the target resource.

[0029] The preset access volume is determined based on the total available volume.

[0030] In one possible implementation, prior to determining the application's resource access time-series data over a single runtime cycle, the method further includes:

[0031] Applications are integrated into the computing device in descending order of priority.

[0032] In one possible implementation, the target resource includes cache bandwidth and / or bus bandwidth.

[0033] Secondly, embodiments of this application provide an application processing apparatus, including:

[0034] A determination module is used to determine resource access time series data of an application within a single runtime cycle. The resource access time series data includes the amount of access to the target resource by the application within each sampling period contained in the runtime cycle. The application is integrated in a computing device containing a multi-core processor.

[0035] The judgment module is used to determine, based on the resource access time series data of each application, whether the total access volume of all applications to the target resource in each sampling period is less than a preset access volume; wherein, the preset access volume is less than or equal to the total available amount of the target resource;

[0036] An adjustment module is used to adjust the design of at least one application if the total number of accesses to the target resource during a target sampling period is greater than or equal to the preset number of accesses.

[0037] In one possible implementation, the determining module is specifically used for:

[0038] The resource access time series data for each application are determined sequentially in descending order of priority.

[0039] Specifically, when determining the resource access time series data of the current application, applications with higher priority than the current application remain running and trigger a preset maximum resource consumption scenario; the priority of the application is positively correlated with its importance to the system functions of the computing device.

[0040] In one possible implementation, the determining module is specifically used for:

[0041] The target resource accesses of the application are counted in each running cycle, and sampled at a preset sampling period to obtain initial resource access time series data;

[0042] Based on the initial resource access time series data corresponding to multiple running cycles, the resource access time series data is constructed based on the maximum access volume of the application in the same sampling period across multiple running cycles.

[0043] In one possible implementation, the determining module is specifically used for:

[0044] Step a: Determine the current application to be overlaid in descending order of priority;

[0045] Step b: For each sampling period, based on the application's resource access time series data, the access volume of the current application to be superimposed in the sampling period is superimposed with the total access volume of the already superimposed applications in the sampling period to obtain the total access volume of the currently superimposed applications in the sampling period.

[0046] Step c: Determine whether the total access volume of the currently overlaid application in each sampling period is less than the preset access volume;

[0047] Step d: If the total access volume of the target sampling period is greater than or equal to the preset access volume, then determine that the total access volume of all applications in the target sampling period is greater than or equal to the preset access volume;

[0048] Step e: If the total access volume of the currently superimposed application in each sampling period is less than the preset access volume, then repeat steps a to d.

[0049] In one possible implementation, the adjustment module is specifically used for:

[0050] If the total access volume of the target sampling period is greater than or equal to the preset access volume, then the access action of the at least one application to the target resource in the target sampling period will be delayed to other sampling periods, wherein the other sampling periods are sampling periods in which the total access volume is less than the preset access volume.

[0051] And / or, reduce the overhead of the at least one application on the target resource during the target sampling period.

[0052] In one possible implementation, before determining the resource access time-series data of the application within a single runtime cycle, the determining module is further configured to:

[0053] Control each master node with resource access capabilities to initiate a maximum resource access request for the target resource;

[0054] When all master nodes are in the state of initiating the maximum resource access request, obtain the maximum access volume of each master node for the target resource;

[0055] The maximum access volume of each master node for the target resource is summed, and the resulting value is determined as the total available amount of the target resource.

[0056] The preset access volume is determined based on the total available volume.

[0057] In one possible implementation, the application processing apparatus further includes an integration module that, prior to determining the application's resource access time-series data over a single runtime cycle, sequentially integrates the application into the computing device in descending order of priority.

[0058] In one possible implementation, the target resource includes cache bandwidth and / or bus bandwidth.

[0059] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0060] The memory stores computer-executed instructions;

[0061] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0062] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0063] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0064] The application processing method, apparatus, and electronic device provided in this application collect time-series data of resource access to shared target resources by each application in a multi-core processor environment, and compare the total access volume within the same sampling period cycle by cycle. This allows for precise location of the target sampling period where the total access volume is greater than or equal to a preset access volume during integration testing, thus identifying the specific time point where multi-core interference occurs. Based on this, design adjustments are made to the applications participating in resource contention within this target sampling period, thereby reducing the risk of multi-core interference during the software design stage. This solution moves the detection and elimination of multi-core interference to the software design stage, ensuring that applications meet the resource constraints of no multi-core interference before integration and deployment. Furthermore, this solution only adjusts the application's resource access within the target sampling period where the total access volume is greater than or equal to the preset access volume. Within the sampling period that does not exceed the limit, the application can fully utilize the target resource, avoiding resource idleness over time. This ensures the performance determinism of the application in a resource contention environment while improving resource utilization, thereby improving the overall performance of the device. Attached Figure Description

[0065] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0066] Figure 1 Flowchart of the application processing method provided in the embodiments of this application Figure 1 ;

[0067] Figure 2 Flowchart of the application processing method provided in the embodiments of this application Figure 2 ;

[0068] Figure 3 Flowchart of the application processing method provided in the embodiments of this application Figure 3 ;

[0069] Figure 4 Flowchart of the application processing method provided in the embodiments of this application Figure 4 ;

[0070] Figure 5 A schematic diagram of the scaling curves of application 1 and application 2 provided in the embodiments of this application;

[0071] Figure 6 A schematic diagram of the total scale curve provided for embodiments of this application. Figure 1 ;

[0072] Figure 7 A schematic diagram of the total scale curve provided for embodiments of this application. Figure 2 ;

[0073] Figure 8 This is a schematic diagram of the structure of the application processing device provided in the embodiments of this application;

[0074] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0075] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0076] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application.

[0077] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with relevant laws, regulations and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0078] First, the application scenarios involved in this application will be explained:

[0079] Avionics systems include a type of platform-based airborne computing device that allows the integration and running of third-party developed applications, and permits the continuous modification of existing applications or the integration of new ones. This characteristic of the airborne computing device enables the functional expansion of avionics systems and the asynchronous development of applications. However, when multiple applications run on the same airborne computing device, preventing interference between them remains a key issue affecting system security and reliability.

[0080] With the continuous development of semiconductor technology, the use of multi-core processors in platform-type onboard computing devices has become increasingly common. The ability of multi-core processors to run multiple applications concurrently further increases the possibility of interference between different applications. For example, when an application running on one processor core frequently and heavily accesses memory over a period of time, an application running on another processor core during the same period may experience reduced efficiency or even deviate from expected results due to limited memory bandwidth being occupied. This phenomenon is commonly referred to as multi-core interference.

[0081] Due to the existence of multi-core interference, multi-application integration activities on multi-core computing platforms face significant technical challenges: because it is difficult to determine whether multi-core interference will adversely affect the security of the current integration results, it is difficult for application integration activities to confirm the final state.

[0082] Currently, avionics R&D companies typically employ technical means to strictly limit the amount of resources each application can use to prevent multi-core interference, thereby ensuring the security and reliability of the integrated results of multiple applications on airborne equipment. Specifically, this involves enabling the Performance Monitoring Unit (PMU) built into the multi-core processor within the multi-core computing platform to monitor the resource consumption of each application in a given runtime cycle in real time. When the multi-core computing platform detects that the resource consumption of an application has reached the pre-allocated limit of available resources for that application, it immediately suspends the application's continued operation to prevent it from overusing the allocated resources. When the next runtime cycle begins, the multi-core computing platform resumes the application's operation and continues to monitor its resource consumption.

[0083] Existing technologies, under the premise of preset static resource quotas, avoid multi-core interference by limiting the excessive use of system resources by each application. However, this approach has a significant technical drawback: the use of system resources by applications is non-uniform in time distribution. The scheme based on preset static resource quotas can lead to the dispersion of system resources, or even idleness for a short period of time, resulting in a significant decrease in the overall performance of onboard computing devices.

[0084] Specifically, if an application reaches the limit of its allocated quota for a certain type of resource, it cannot utilize the unused resources even if other applications are not using the same type of resource, thus reducing the overall utilization of system resources. Each application can only obtain access to a portion of system resources, and under resource constraints, the efficiency of applications in completing their intended functions decreases. This performance degradation worsens rapidly with the increase in the number of cores in multi-core processors. Taking the currently common 8-core processor as an example, applications on each core can only obtain an average of 1 / 8 of the system resources, and the efficiency of applications in completing their intended functions is correspondingly reduced significantly.

[0085] In summary, existing technologies suffer from low resource utilization and reduced performance.

[0086] Based on the aforementioned technical problems, the technical concept of this application is as follows: Addressing the technical shortcomings of existing technologies where preset static resource quotas lead to the dispersion or even idleness of system resources, resulting in a significant decline in the overall performance of airborne computing devices, the inventors, by analyzing the causal relationship between resource contention and interference phenomena among applications in multi-core processors, recognize that the distribution of the number of system resource accesses by applications running on airborne computing devices containing multi-core processors generally fluctuates over time. When multiple processor cores concurrently run multiple applications, multi-core interference caused by resource contention only occurs when the number of resource accesses by applications exceeds the total system resources. If the number of resource accesses does not exceed the total system resources, multi-core interference will not actually occur.

[0087] Based on this understanding, the inventors propose that if the refined resource consumption characteristics of each application over time can be obtained during the design phase, thereby identifying the specific time periods where resource access exceeds the total system resources, instead of passively limiting rates at runtime, it is hoped that multi-core interference can be fundamentally eliminated. Specifically, during the application design phase, on a per-cycle basis, it can be determined whether the total access volume of all applications in each sampling cycle is less than the preset access volume. If the total access volume of the target resource in a target sampling cycle is greater than or equal to the preset access volume, then the design of at least one application can be adjusted. This can overcome the problems of low resource utilization and reduced performance caused by static quota schemes while avoiding multi-core interference.

[0088] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0089] Figure 1 Flowchart of the application processing method provided in the embodiments of this application Figure 1 ,like Figure 1 As shown, the method includes:

[0090] S11. Determine the time-series data of resource access for the application within a single runtime cycle.

[0091] The execution subject of this application embodiment is an electronic device, which can be a terminal device, such as a laptop, desktop computer, tablet computer, test computer, or computing device that includes a multi-core processor and integrates multiple applications, or it can be a server. In practical applications, whether the electronic device is a terminal device or a server can be determined according to the actual situation, and there is no specific limitation on this.

[0092] Among them, resource access time series data is a collection of access volume data arranged in chronological order, used to characterize the amount of access to the target resource by the application within each sampling period contained in the running cycle.

[0093] For example, the sampling period can be 5μs, 10μs or 15μs, which can be preset according to empirical or experimental values. This application embodiment does not impose specific limitations on this.

[0094] It is understandable that the sampling period is shorter than the running period.

[0095] For example, a single running cycle may contain multiple sampling cycles, and the number of sampling cycles can be preset based on empirical or experimental values. This application embodiment does not impose specific limitations on this.

[0096] For example, resource access time series data can be represented by tables, curves, etc. This application embodiment does not impose specific restrictions on the way resource access time series data is expressed.

[0097] The target resource is a shared resource that cannot be managed by the computing device and is accessed by multiple applications running concurrently. For example, in a computing device, the target resource can be cache bandwidth, bus bandwidth, or other shared hardware resources that can create competition.

[0098] Alternatively, the target resource can also be memory, storage, network bandwidth, etc.

[0099] The application is integrated into a computing device that includes a multi-core processor.

[0100] For example, the number of applications is at least two, which can be preset based on empirical or experimental values. This application embodiment does not impose specific limitations on this.

[0101] Specifically, a multi-core processor is used to support the concurrent execution of multiple applications, with tasks on different cores accessing shared resources in overlapping or staggered timeframes during operation. For example, a multi-core processor may contain at least two cores; the number of cores can be determined based on actual needs, and this application does not impose specific limitations on this.

[0102] The computing device is a platform-type avionics device that can provide a multi-core processing environment and resource monitoring conditions for flight control, avionics management, navigation, or communication missions.

[0103] In this context, a single running cycle refers to a complete business execution cycle of the application. The length of the cycle can be determined based on the application's design documents, task scheduling table, or time partitioning configuration, such as 25ms, 30ms, or 40ms. This application embodiment does not impose specific limitations on this.

[0104] For each application, within a single runtime cycle, the target resource is continuously sampled at a pre-defined sampling period, and the access volume collected in each sampling period is arranged in chronological order to form the resource access time series data of the application.

[0105] It should be understood that the specific implementation process and principle of this step will be described in detail in subsequent embodiments, and will not be repeated here.

[0106] S12. Based on the resource access time series data of each application, determine whether the total access volume of all applications to the target resource in each sampling period is less than the preset access volume.

[0107] The preset access limit is the upper limit allowed for all applications to share the target resource within a single sampling period, which is less than or equal to the total available amount of the target resource. The total available amount refers to the resource capacity that the target resource can actually be allocated to applications under the current computing device hardware capabilities and system constraints.

[0108] In one possible implementation, for each sampling period, the access volume of each application in that sampling period can be summed based on the resource access time series data of each application to obtain the total access volume of all applications in that sampling period. Then, it is determined whether the total access volume for all sampling periods is less than a preset access volume.

[0109] In another possible implementation, S12 can be achieved through the following steps:

[0110] Step a: Determine the current application to be overlaid in order of priority from high to low.

[0111] The priority of an application is positively correlated with its importance to the system functions of a computing device.

[0112] In practical applications, the importance of an application to the system functionality of a computing device can be reflected in its security level, whether it provides public services, and its resource consumption. Applications with high security levels, providing public services, and consuming a lot of resources have high priority, while applications with low security levels, not providing public services, and consuming little resources have low priority.

[0113] Optionally, the priority of each application can be stored in a priority table. In this priority table, the application identifiers can be sorted in descending or ascending order of priority, or the application identifiers can be sorted randomly.

[0114] For example, suppose the applications are sorted in descending order of priority, resulting in the sequence Application 1, Application 2, and Application 3. In the specific processing, Application 1 is first identified as the application to be overlaid. When step a is executed again, Application 2 is identified as the application to be overlaid.

[0115] Step b: For each sampling period, based on the application's resource access time series data, the access volume of the current application to be overlaid in the sampling period is overlaid with the total access volume of the already overlaid applications in the sampling period to obtain the total access volume of the currently overlaid applications in the sampling period.

[0116] It should be understood that overlaid applications are those with higher priority than the applications to be overlaid. For each sampling period, the total access volume of overlaid applications in that sampling period is the sum of the access volumes of all overlaid applications in that sampling period.

[0117] Based on the example in step a, when application 2 is the current application to be overlaid, application 1 is the overlaid application; when application 3 is the current application to be overlaid, application 1 and application 2 are the overlaid applications. The sum of the access volume of application 1 and application 2 in the same sampling period is the total access volume of the overlaid application in that sampling period.

[0118] Step c: Determine whether the total access volume of the currently overlaid application in each sampling period is less than the preset access volume.

[0119] Step d: If the total access volume of the target resource in the target sampling period is greater than or equal to the preset access volume, then determine that the total access volume of all applications in the target sampling period is greater than or equal to the preset access volume.

[0120] Step e: If the total access volume of the currently superimposed applications in each sampling period is less than the preset access volume, then repeat steps a to d until the judgment of all applications is completed.

[0121] In this implementation, the access volume of each application in the current sampling period is superimposed one by one in descending order of priority. This allows for immediate detection after each superposition whether the total access volume of the superimposed applications exceeds or equals a preset access volume in a given sampling period. This accurately pinpoints the sampling period in which the total access volume first exceeds or equals the preset access volume, and identifies the set of applications already involved in the superposition at that time. Since the superposition order is positively correlated with priority, the applications superimposed first are more critical to system functionality. Therefore, it can be determined that newly added applications in the current round are the direct trigger for the total access volume exceeding or equaling the preset access volume in that sampling period. This provides a clear decision-making basis for subsequent adjustments to the design of at least one application: prioritizing adjustments to the resource access behavior of the newly added application within the target sampling period, or seeking optimization opportunities in higher-priority superimposed applications. This eliminates multi-core interference with minimal adjustment cost while ensuring that high-priority applications are not affected.

[0122] S13. If the total number of accesses to the target resource during the target sampling period is greater than or equal to the preset number of accesses, then the design of at least one application shall be adjusted.

[0123] Among them, at least one application can be an application with a high proportion of access volume during the target sampling period, an application whose access timing overlaps with other applications, or an application with low priority.

[0124] For example, the number of applications can be one, two, three, or more, and this application embodiment does not impose a specific limitation on this.

[0125] In one possible implementation, if the total number of accesses to the target resource in a target sampling period is greater than or equal to a preset number of accesses, then at least one application's access to the target resource in the target sampling period will be delayed to other sampling periods.

[0126] Among them, the access action refers to the read, write, transfer or call operation initiated by the application for the target resource, and the other sampling period is the sampling period when the total access volume is less than the preset access volume.

[0127] Specifically, when it is determined that the total access volume of the target sampling period is greater than or equal to the preset access volume, the application that contributes more to the total access volume can be selected based on the access distribution of each application in the target sampling period. The resource access actions originally scheduled for that sampling period are cached in the execution queue. Then, the execution time is reallocated according to the remaining access capacity of other sampling periods, so that the resource access action is moved to a sampling period with a total access volume less than the preset access volume.

[0128] In practical applications, if the remaining access capacity of other sampling periods closest to the target sampling period is greater than or equal to the total access volume of all resource access actions in the queue to be executed, then all resource access actions are directly assigned to that other sampling period for execution. If the remaining access capacity of that other sampling period is less than the total access volume of all resource access actions in the queue to be executed, then some access actions corresponding to the remaining access capacity are first assigned to that other sampling period. Then, in order of increasing distance from the target sampling period, the next other sampling period with a total access volume less than the preset access volume is selected. The remaining access capacity calculation and access action allocation operation are repeated until all resource access actions in the queue to be executed are completed and reallocated. Furthermore, the total access volume of all other sampling periods with allocated resource access actions is still less than the preset access volume after allocation. Ultimately, the resource access actions originally concentrated in the target sampling period are dispersed and migrated to multiple surrounding other sampling periods with a total access volume less than the preset access volume for execution.

[0129] In another possible implementation, the overhead of at least one application on the target resource is reduced during the target sampling period.

[0130] Specifically, the resource usage intensity of at least one application within the target sampling period can be reconstructed by compressing the amount of resources accessed in a single session, reducing the number of repeated accesses, merging adjacent access requests, or shortening the access holding time.

[0131] It is understood that the above two methods can be implemented individually or in combination, and the embodiments of this application do not impose specific restrictions on this.

[0132] Understandably, after adjusting the design of at least one application, it is necessary to re-execute S11-S13, that is, to re-acquire the resource access time series data of all applications in a single runtime cycle after the adjustment, and to perform the total access volume summation and comparison process again. If the total access volume is less than the preset access volume in all adjusted sampling cycles, then the current design is taken as the application design scheme that meets the condition of no multi-core interference; if the total access volume in the target sampling cycle is still greater than or equal to the preset access volume, then the design adjustment continues until the total access volume is less than the preset access volume in all adjusted sampling cycles, or the number of iterations reaches the preset number of iterations.

[0133] In both of the above methods, after detecting that the total access volume of the target sampling period is greater than or equal to the preset access volume, resource access during the high-contention period (target sampling period) is transferred to the low-contention period (other sampling periods), or the resource occupancy during the target sampling period is directly reduced, so that the instantaneous load of shared resources falls back to within the preset access volume and matches the concurrent operation state in multi-core computing devices. These two methods can reduce the concentrated occupancy of shared resources in local periods and make the concurrent operation of multiple applications in the onboard environment more stable, facilitating resource reallocation without changing the overall application functionality.

[0134] The application processing method provided in this application first determines the resource access time series data of the application within a single runtime cycle, and then, based on the resource access time series data of each application, determines whether the total access volume of all applications in each sampling cycle is less than a preset access volume. If the total access volume of the target resource in a target sampling cycle is greater than or equal to the preset access volume, the design of at least one application is adjusted. The resource access time series data includes the access volume of the application to the target resource in each sampling cycle contained in the runtime cycle. The application is integrated into a computing device containing a multi-core processor, and the preset access volume is less than or equal to the total available target resource.

[0135] By collecting time-series data on resource access to shared target resources from each application in a multi-core processor environment and comparing the total access volume period by period within the same sampling period, the system can accurately pinpoint the target sampling period where the total access volume is greater than or equal to a preset access volume during integration testing, thus identifying the specific time point when multi-core interference occurs. Based on this, design adjustments are made to applications participating in resource contention within this target sampling period, thereby reducing the risk of multi-core interference during the software design phase. This solution moves the detection and elimination of multi-core interference to the software design stage, ensuring that applications meet the resource constraints of being free from multi-core interference before integration and deployment. Furthermore, this solution only adjusts application resource access within the target sampling period where the total access volume is greater than or equal to the preset access volume. Within the sampling period within the limit, applications can fully utilize the target resources, avoiding resource idleness over time. This ensures the performance determinism of applications in resource contention environments while improving resource utilization, thereby improving overall device performance.

[0136] Next, the specific implementation process of S11 will be explained.

[0137] Optionally, in some embodiments, S11 can be implemented by the following steps: determining the resource access time series data of each application in descending order of priority.

[0138] Specifically, when determining the resource access time-series data of the current application, applications with higher priority remain running and trigger a preset maximum resource consumption scenario. The application priority is positively correlated with its importance to the system functions of the computing device.

[0139] In the specific implementation, multiple applications are sorted according to a pre-established priority table, and each application is sampled sequentially within a single runtime cycle. When sampling the current application, all tasks with higher priority than the current application continue to execute, causing them to occupy the target resources. High-occupancy data access requests are injected into the current application through test incentives, or its original load is maintained and background contention load is added to create a scenario of maximum resource consumption for the target resources.

[0140] By sequentially determining the resource access time series data of each application in descending order of priority, and ensuring that high-priority applications are running and triggering the maximum resource consumption scenario during the current application sampling, the current application is always in a resource contention environment equivalent to real concurrent operation. This method ensures that the collected resource access time series data reflects the resource access characteristics of the current application under the most unfavorable conditions, rather than its idealized performance when it monopolizes resources. Since multi-core interference only occurs when the total access volume exceeds the total system resources, subsequent overlay analysis based on the application data collected under the most unfavorable conditions can avoid overlooking potential overruns during actual concurrency due to underestimating peak resource consumption. This provides a reliable data foundation for accurately determining whether the total access volume in the target sampling period is greater than or equal to the preset access volume, avoiding inadequate adjustments due to data distortion.

[0141] Optionally, in some embodiments, the resource access time series data for each application described above can be determined by... Figure 2 The implementation is carried out in the example shown.

[0142] Figure 2 Flowchart of the application processing method provided in the embodiments of this application Figure 2 ,like Figure 2 As shown, the method includes:

[0143] S21. Count the access to target resources of the application in each running cycle and sample them at a preset sampling period to obtain initial resource access time series data.

[0144] In one possible implementation, a hardware resource access counting mechanism can be used to perform hardware-level event counting for every target resource access event that occurs during the application's runtime cycle. The cumulative count value at each sampling time is read according to a preset sampling period, resulting in a time-ordered sequence of discrete count points. For the first sampling period, the cumulative count value of the first sampling period is subtracted from the fixed sampling offset of the hardware resource access counting mechanism to obtain the actual number of accesses to the target resource within the first sampling period. For the second sampling period and each subsequent sampling period, the cumulative count value of the current sampling period is subtracted from the cumulative count value of the previous sampling period; the difference is the actual number of accesses to the target resource within the current sampling period. Arranging the access values ​​of each sampling period in time order yields the initial resource access time series data.

[0145] The fixed sampling offset refers to the fixed initial deviation value that is superimposed on the cumulative count value read at any sampling time due to the inherent working characteristics of the hardware resource access counting mechanism. This deviation value does not correspond to any actual target resource access event and remains constant throughout the entire running cycle.

[0146] Since the cumulative count values ​​read at all sampling times contain the same fixed sampling offset, and the fixed sampling offset has been explicitly deducted in the first sampling period and automatically canceled out when the difference is calculated in subsequent adjacent sampling periods, the difference obtained in each sampling period after differential processing only reflects the actual number of accesses to the target resource that occurred in that period.

[0147] S22. Based on the initial resource access time series data corresponding to multiple running cycles, construct resource access time series data based on the maximum access volume of the application in the same sampling period in multiple running cycles.

[0148] Based on the initial resource access time series data corresponding to multiple operating cycles, the access volume corresponding to the same sampling cycle in multiple operating cycles is compared, and the maximum value is taken as the final access volume of that sampling cycle. The final access volumes of each sampling cycle are then combined in chronological order to form resource access time series data.

[0149] In the above embodiments, the initial resource access time series data is the cumulative count value output by the hardware resource access counting mechanism. After differential processing, the cumulative count value is converted into the actual access volume to the target resource in each sampling period, eliminating the interference of count accumulation on data interpretation. By repeatedly sampling multiple running periods and taking the maximum value of the same sampling period, the peak access information of each sampling period under the worst-case conditions is retained, avoiding the underestimation of peak resource usage due to random fluctuations in a single sampling. The resource access time series data constructed in this way can reflect the access intensity and time distribution characteristics of the application to the target resource under the worst-case scenario, providing a reliable data foundation for subsequent determination of whether the total access volume of multiple applications in the same sampling period is greater than or equal to the preset access volume.

[0150] Next, through Figure 3 The illustrated embodiment provides a detailed explanation of the method for determining the preset access volume corresponding to the target resource.

[0151] Figure 3 Flowchart of the application processing method provided in the embodiments of this application Figure 3 ,like Figure 3 As shown, prior to S11, the method further includes:

[0152] S31. Control each master node with resource access capabilities to initiate a maximum resource access request for the target resource.

[0153] Among them, maximizing resource access requests is used to determine the upper limit of access that the master node can achieve to the target resource.

[0154] For example, the number of master nodes can be 1, 2 or 3, etc., which can be determined according to the actual situation. This application embodiment does not impose a specific limit on the number of master nodes.

[0155] For example, the master node can be a CPU core, a Direct Memory Access (DMA) controller, and peripherals with DMA capabilities.

[0156] In one possible implementation, each master node can be controlled to simultaneously initiate a maximum resource access request for the target resource.

[0157] In practical implementation, control commands can be sent to each master node, enabling each master node to initiate a maximum resource access request for the target resource simultaneously. It should be understood that these control commands can be sent in parallel or triggered in a pre-defined polling order.

[0158] In another possible implementation, each master node can be controlled to initiate a maximum resource access request for the target resource within a preset time period (e.g., 0.2 seconds, 0.4 seconds, or 0.6 seconds).

[0159] S32. When all master nodes are in the state of initiating maximum resource access requests, obtain the maximum access volume of each master node for the target resource.

[0160] In one possible implementation, the access volume of each master node on the target resource can be collected in real time, and the peak value within the collection window can be used as the maximum access volume of the corresponding master node.

[0161] S33. The maximum access volume of each master node for the target resource is summed, and the resulting value is determined as the total available amount of the target resource.

[0162] S34. Determine the preset access volume based on the total available volume.

[0163] In one possible implementation, the preset access limit can be determined by subtracting the preset security access limit from the total available amount.

[0164] In another possible implementation, the preset access limit can be determined by multiplying the total available amount by a preset security ratio.

[0165] It is understood that the aforementioned preset secure access volume and preset security ratio can be determined based on system design and security margin considerations, through empirical or experimental values, and this application embodiment does not impose specific restrictions on them.

[0166] Both of these methods ensure that, after the final integration is completed, the total actual resource consumption will always be far away from the total available resources, reserving a certain amount of access as a buffer.

[0167] In another possible implementation, the total available quantity can be determined as the preset access quantity.

[0168] In the above embodiments, the preset access volume no longer relies on a fixed empirical value, but is determined by the total available amount of the target resources, thus corresponding to the actual carrying capacity of shared resources in a multi-core computing device. This allows subsequent judgments on the timing of application resource access to be based on the actual resource limit, thereby improving the accuracy of the preset access volume setting and the consistency of resource access control.

[0169] Alternatively, in addition to the above Figure 3 In addition to the embodiments shown, the total available amount of the target resource can also be determined in the following ways.

[0170] During the system design phase of computing devices, the total available amount of target resources (such as memory, storage, and network bandwidth) that can be fully controlled by the platform is usually clearly stated in the design documents or technical specifications. In actual implementation, the device hardware configuration information or design specification parameters can be directly read, and the total available amount of the target resources recorded therein can be determined as the total available amount of the target resources.

[0171] It is understood that in practical applications, the total available amount can be obtained through other existing means based on the type and characteristics of the target resource. This application does not specifically limit the method of obtaining the total available amount of the target resource.

[0172] Before determining the application's resource access time-series data within a single runtime cycle, applications can be integrated into the computing device sequentially in descending order of priority.

[0173] In practice, the highest-priority application is first deployed to the computing device. Its startup parameters are configured, running permissions are assigned, and the mapping relationship with target resources is established. It is then confirmed that the application can start and run normally on the device. Based on this, the deployment status of this application remains unchanged, and the next highest-priority application is deployed to the same computing device. The above configuration and confirmation process is repeated until all applications are integrated in sequence.

[0174] For example, suppose there are three applications, with priority from highest to lowest: application A, application B, and application C. First, application A is integrated into the computing device and its runtime configuration is completed. While application A remains deployed, application B is integrated into the device. Finally, while both application A and application B remain deployed, application C is integrated into the device.

[0175] In this embodiment, applications are integrated sequentially in descending order of priority, allowing high-priority applications to occupy the runtime environment and resource mappings first. Since the integration order is positively correlated with the importance of the applications to system functionality, when system resources are insufficient to meet the resource access needs of all applications, the resource usage of high-priority applications remains unaffected, while the resource access timing of low-priority applications is restricted or adjusted. This prioritizes the resource needs of important applications, ensuring the reliable operation of core system functions while avoiding multi-core interference.

[0176] To more clearly explain the scheme shown in the above embodiments, let's take a computing device containing a multi-core processor as an example. Figure 4 The illustrated embodiments will be further explained.

[0177] Figure 4 Flowchart of the application processing method provided in the embodiments of this application Figure 4 ,like Figure 4 As shown, the method includes:

[0178] S41. Determine the total available amount of the target resources.

[0179] S42. Determine the proportion sequence data for each application in descending order of priority.

[0180] The performance monitoring unit built into the multi-core processor counts the access to target resources for each application in each runtime cycle according to priority. The access counts of shared resources are sampled at a certain frequency to obtain a time-series sequence of discrete count points. This sequence is then differentially processed to obtain initial resource access time-series data. Multiple sampling operations are performed to obtain multiple initial resource access time-series data. Based on these multiple initial resource access time-series data, the maximum access volume of the application in the same sampling period across multiple runtime cycles is determined, thus constructing the resource access time-series data.

[0181] For example, for an application with a runtime of 25ms, 2500 data points are continuously collected with a sampling period of 10μs.

[0182] Optionally, average resource access time series data can be constructed based on the average access volume of the application in the same sampling period across multiple operating cycles; minimum resource access time series data can also be constructed based on the minimum access volume of the application in the same sampling period across multiple operating cycles.

[0183] Furthermore, the access volume of the target resource in each sampling period of the application's resource access time series data can be divided by the total available amount to obtain the ratio of access volume to the total available amount. The ratios of each sampling period can be arranged in chronological order to form a ratio series data.

[0184] For example, assuming the computing device is a dual-core processor, integrating application 1 and application 2, and the target resource is memory bandwidth, the proportional sequence data of application 1 and the proportional sequence data of application 2 can be represented by Table 1.

[0185] Table 1. Proportional sequence data for Application 1 and Application 2

[0186]

[0187] In Table 1, the first row is the sampling period, the first column is the application identifier, and the table values ​​are the proportions in the proportional sequence data, in units of %.

[0188] Using the sampling period as the horizontal axis and the proportion as the vertical axis, the proportion sequence data is mapped into a proportion curve. The proportion curve is used to visually display the time distribution of the proportion of target resources occupied by the application within a single running cycle.

[0189] Figure 5 This is a schematic diagram showing the scaling curves of application 1 and application 2 provided in embodiments of this application. Figure 5 As shown, the horizontal axis represents the sampling period, and the vertical axis represents the percentage (%). The blue curve represents the percentage curve of application 1, and the orange curve represents the percentage curve of application 2.

[0190] S43. Determine whether the proportional sequence data of all applications has been obtained.

[0191] If yes, then execute S44; otherwise, execute S42.

[0192] S44. For each sampling period, sum up the proportion of access volume of all applications in that sampling period to the total available volume in descending order of priority.

[0193] The proportion curves of all applications are superimposed in descending order of priority to obtain the total proportion curve of the target resources when multiple applications are integrated into a computing device with a multi-core processor and run concurrently.

[0194] Based on the S42 example, the overall scale curve obtained by superimposing the scale curves of application 1 and application 2 is obtained by... Figure 6 To express.

[0195] Figure 6 A schematic diagram of the total scale curve provided for embodiments of this application. Figure 1 .like Figure 6 As shown, the horizontal axis represents the sampling period, and the vertical axis represents the proportion in %. The proportion of the total proportion curve during T3-T5 is greater than or equal to 100%, which means that if Application 1 and Application 2 are integrated into the computing device according to their current design, multi-core interference will inevitably occur during T3-T5, thus causing them to fail to achieve the expected functions and performance.

[0196] S45. Determine whether the total proportion of all sampling periods is less than 100%.

[0197] If not, i.e., there is a target sampling period with a total proportion greater than or equal to 100%, then execute S46; if yes, then end.

[0198] S46. Adjust the design of at least one application.

[0199] Identify the target sampling period with a total proportion greater than or equal to 100% and the applications that consume relatively more target resources. Analyze the rationality of the target resource consumption of these applications within the target sampling period, assess the optimization potential, and attempt to adjust the application design to reduce the total consumption of target resources within the target sampling period. For example, reduce the resource overhead of each application, or adjust the timing of resource consumption by applications that consume relatively more target resources.

[0200] After executing S46, execute S42 again until the total percentage of all sampling periods is less than 100%.

[0201] Based on examples S42 and S44, after adjustments to the design of at least one application, the proportional sequence data of application 1 and the proportional sequence data of application 2 can be represented by Table 2.

[0202] Table 2. Proportional sequence data for Application 1 and Application 2

[0203]

[0204] In Table 2, the first row is the sampling period, the first column is the application identifier, and the table values ​​are the proportions in the proportional sequence data, in units of %.

[0205] Figure 7 A schematic diagram of the total scale curve provided for embodiments of this application. Figure 2 .like Figure 7 As shown, the horizontal axis represents the sampling period, and the vertical axis represents the percentage, with the unit being %. Delaying the resource access (T1-T2) of application 2 by 2 sampling periods keeps the total percentage curve below 80%, thus alleviating the multi-core interference between the two applications.

[0206] It is understandable that the pressure to relieve resource consumption can be borne by a single application or by multiple applications. This example only demonstrates the effect of adjusting the design of a single application on mitigating multi-core interference.

[0207] The modified design is then incorporated into the application implementation. S42 to S46 are repeated to perform re-verification and re-optimization until it is confirmed that there is still no multi-core interference or risk between all applications in the system under the worst case. The final regression result is the condition for achieving multi-application integration under multi-core interference environment.

[0208] In summary, when computing devices employ multi-core processors, multiple applications will execute concurrently on different processor cores. Due to the limitations of current multi-core processor hardware design, some target resources will inevitably be shared across multiple cores. Whether multi-core interference occurs when applications on multiple cores simultaneously access the same shared target resource depends not on whether the resource consumption of a single application exceeds a static limit, but rather on whether the sum of accesses to the target resource by all applications at any given time exceeds the total available amount of that target resource. Based on this understanding, this application provides an application processing method that, while ensuring no multi-core interference occurs during the concurrent execution of multiple applications, effectively avoids resource idleness and waste caused by preset static resource quota schemes by relaxing the restrictions on the use of target resources by individual applications, thereby balancing the utilization rate of target resources with the overall performance of the device.

[0209] The technical benefits of this method are specifically reflected in the following aspects:

[0210] First, the conditions for multi-core interference have been redefined. High consumption of target resources by a single application does not necessarily lead to multi-core interference; multi-core interference only occurs when the sum of accesses to the target resource by all concurrent applications at the same time is greater than or equal to the total available resources. This provides a theoretical basis for shifting resource allocation from static quotas to "dynamic coordination."

[0211] Second, the consumption of target resources by applications exhibits non-uniformity over time. Each application does not continuously occupy the target resources, but rather operates in a pattern of short-term occupation, immediate release, and periodic or irregular repetition, with its resource consumption showing alternating peaks and troughs in its temporal distribution. This volatility creates conditions for multiple applications to avoid competition by using resources at off-peak times.

[0212] Third, multi-core interference can be avoided through two types of design adjustments. First, multiple applications can coordinate their access to the target resource at the same time, so that the total access is less than or equal to the total available resources. Second, resource access can be staggered in time by avoiding the peak periods when applications occupy the target resource.

[0213] Fourth, the aforementioned design adjustments rely on the accurate acquisition of resource consumption characteristics. During the testing phase, the hardware resource access counting mechanism can accurately measure the resource access time series data of each application. By superimposing the data from each application, the total access volume of all applications in each sampling period can be obtained. By comparing the total access volume of any sampling period with the preset access volume of the target resource, the time intervals where multi-core interference exists can be accurately identified.

[0214] Fifth, the identified multi-core interference range can be mitigated or avoided by adjusting the design of relevant applications.

[0215] Sixth, through re-verification and re-optimization until the total access volume of all applications to the target resource is always less than the preset access volume throughout the entire runtime, it can be ensured that there is no longer multi-core interference caused by resource contention between multiple applications running concurrently on a multi-core processor, thus completing the final confirmation of multi-application integration.

[0216] Figure 8 This is a schematic diagram of the structure of the application processing device provided in the embodiments of this application, such as... Figure 8 As shown, the application processing device 80 provided in this embodiment includes:

[0217] The determination module 801 is used to determine the resource access time series data of the application in a single runtime cycle. The resource access time series data includes the amount of access to the target resource by the application in each sampling period contained in the runtime cycle. The application is integrated in a computing device containing a multi-core processor.

[0218] The judgment module 802 is used to determine, based on the resource access time series data of each application, whether the total access volume of all applications to the target resource in each sampling period is less than a preset access volume. The preset access volume is less than or equal to the total available amount of the target resource.

[0219] The adjustment module 803 is used to adjust the design of at least one application if the total number of accesses to the target resource during the target sampling period is greater than or equal to the preset number of accesses.

[0220] In one possible implementation, the determining module 801 is specifically used for:

[0221] The resource access time series data for each application are determined sequentially in descending order of priority.

[0222] Specifically, when determining the resource access time-series data of the current application, applications with higher priority remain running and trigger a preset maximum resource consumption scenario. The application priority is positively correlated with its importance to the system functions of the computing device.

[0223] In one possible implementation, the determining module 801 is specifically used for:

[0224] The target resource accesses of the application are counted in each running cycle, and sampled at a preset sampling period to obtain initial resource access time series data.

[0225] Based on the initial resource access time series data corresponding to multiple running cycles, and the maximum access volume of the application in the same sampling period across multiple running cycles, resource access time series data is constructed.

[0226] In one possible implementation, the determination module 802 is specifically used for:

[0227] Step a: Determine the current application to be overlaid in order of priority from high to low.

[0228] Step b: For each sampling period, based on the application's resource access time series data, the access volume of the current application to be overlaid in the sampling period is overlaid with the total access volume of the already overlaid applications in the sampling period to obtain the total access volume of the currently overlaid applications in the sampling period.

[0229] Step c: Determine whether the total access volume of the currently overlaid application in each sampling period is less than the preset access volume.

[0230] Step d: If the total access volume of the target resource in the target sampling period is greater than or equal to the preset access volume, then determine that the total access volume of all applications in the target sampling period is greater than or equal to the preset access volume.

[0231] Step e: If the total number of accesses of the currently superimposed application in each sampling period is less than the preset number of accesses, then repeat steps a to d.

[0232] In one possible implementation, the adjustment module 803 is specifically used for:

[0233] If the total number of accesses to the target resource in the target sampling period is greater than or equal to the preset number of accesses, then the access actions of at least one application to the target resource in the target sampling period will be delayed to other sampling periods, which are sampling periods in which the total number of accesses is less than the preset number of accesses.

[0234] And / or, reduce the overhead of at least one application on the target resource within the target sampling period.

[0235] In one possible implementation, before determining the application's resource access time-series data over a single runtime cycle, the determining module 801 is further configured to:

[0236] Control each master node with resource access capabilities to initiate a maximum resource access request for the target resource.

[0237] When all master nodes are in the state of initiating maximum resource access requests, obtain the maximum access volume of each master node for the target resource.

[0238] The maximum access volume of each master node for the target resource is summed, and the resulting value is determined as the total available amount of the target resource.

[0239] The preset access limit is determined based on the total available amount.

[0240] In one possible implementation, the application processing device 80 further includes an integration module that integrates the application into the computing device in descending order of priority before determining the application's resource access time-series data over a single runtime cycle.

[0241] In one possible implementation, the target resources include cache bandwidth and / or bus bandwidth.

[0242] The application processing device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0243] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 9 As shown, the electronic device 90 provided in this embodiment includes at least one processor 901 and a memory 902. Optionally, the electronic device 90 further includes a communication component 903. The processor 901, memory 902, and communication component 903 are connected via a bus 904.

[0244] In a specific implementation, at least one processor 901 executes computer execution instructions stored in memory 902, causing at least one processor 901 to perform the above-described method.

[0245] Optionally, the processor 901 includes multiple cores and integrates multiple applications to ensure that, after executing the above application processing method, multiple applications running on the cores do not experience multi-core interference.

[0246] The specific implementation process of processor 901 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0247] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0248] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0249] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0250] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0251] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0252] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0253] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an application-specific integrated circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0254] The division of units is merely a logical functional division; 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 indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0255] 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.

[0256] 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.

[0257] If a function is implemented as a software functional unit and sold or used as an independent product, it 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 of 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, ROM, RAM, magnetic disks, or optical disks.

[0258] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0259] Finally, it should be noted that other embodiments of this application will readily conceive of by those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes may be made without departing from its scope.

Claims

1. An application processing method, characterized in that, include: Determine resource access time series data for an application within a single runtime cycle, the resource access time series data including the amount of access to a target resource by the application within each sampling period contained in the runtime cycle, the application being integrated into a computing device containing a multi-core processor; Based on the resource access time series data of each application, determine whether the total access volume of all applications to the target resource in each sampling period is less than a preset access volume; wherein, the preset access volume is less than or equal to the total available amount of the target resource; If the total number of accesses to the target resource during the target sampling period is greater than or equal to the preset number of accesses, then the design of at least one application will be adjusted.

2. The method according to claim 1, characterized in that, The determination of the application's resource access time-series data within a single runtime cycle includes: The resource access time series data for each application are determined sequentially in descending order of priority. Specifically, when determining the resource access time series data of the current application, applications with higher priority than the current application remain running and trigger a preset maximum resource consumption scenario; the priority of the application is positively correlated with its importance to the system functions of the computing device.

3. The method according to claim 2, characterized in that, The determination of the resource access time series data for each application includes: The target resource accesses of the application are counted in each running cycle, and sampled at a preset sampling period to obtain initial resource access time series data; Based on the initial resource access time series data corresponding to multiple running cycles, the resource access time series data is constructed based on the maximum access volume of the application in the same sampling period across multiple running cycles.

4. The method according to claim 2 or 3, characterized in that, The step of determining whether the total access volume of all applications to the target resource in each sampling period is less than a preset access volume based on the resource access time series data of each application includes: Step a: Determine the applications to be overlaid in descending order of priority; Step b: For each sampling period, based on the resource access time series data of the application, the access volume of the current application to be superimposed in the sampling period is superimposed with the total access volume of the superimposed applications in the sampling period to obtain the total access volume of the current superimposed applications in the sampling period. Step c: Determine whether the total access volume of the currently overlaid application in each sampling period is less than the preset access volume; Step d: If the total access volume of the target sampling period is greater than or equal to the preset access volume, then determine that the total access volume of all applications in the target sampling period is greater than or equal to the preset access volume; Step e: If the total access volume of the currently superimposed application in each sampling period is less than the preset access volume, then repeat steps a to d.

5. The method according to any one of claims 1-3, characterized in that, If the total access volume of the target resource during a target sampling period is greater than or equal to the preset access volume, then the design of at least one application is adjusted, including: If the total access volume of the target resource in the target sampling period is greater than or equal to the preset access volume, then the access action of the at least one application to the target resource in the target sampling period will be delayed to another sampling period, wherein the other sampling period is a sampling period in which the total access volume is less than the preset access volume. And / or, reduce the overhead of the at least one application on the target resource during the target sampling period.

6. The method according to any one of claims 1-3, characterized in that, Prior to determining the application's resource access time-series data over a single runtime cycle, the method further includes: Control each master node with resource access capabilities to initiate a maximum resource access request for the target resource; When all master nodes are in the state of initiating the maximum resource access request, obtain the maximum access volume of each master node for the target resource; The maximum access volume of each master node for the target resource is summed, and the resulting value is determined as the total available amount of the target resource. The preset access volume is determined based on the total available volume.

7. The method according to claim 2 or 3, characterized in that, Prior to determining the application's resource access time-series data over a single runtime cycle, the method further includes: Applications are integrated into the computing device in descending order of priority.

8. The method according to any one of claims 1-3, characterized in that, The target resources include cache bandwidth and / or bus bandwidth.

9. An application processing device, characterized in that, include: A determination module is used to determine resource access time series data of an application within a single runtime cycle. The resource access time series data includes the amount of access to the target resource by the application within each sampling period contained in the runtime cycle. The application is integrated in a computing device containing a multi-core processor. The judgment module is used to determine, based on the resource access time series data of each application, whether the total access volume of all applications to the target resource in each sampling period is less than a preset access volume; wherein, the preset access volume is less than or equal to the total available amount of the target resource; An adjustment module is used to adjust the design of at least one application if the total access volume of the target resource during a target sampling period is greater than or equal to the preset access volume.

10. An electronic device, characterized in that, include: Memory and processor; The memory stores computer-executed instructions; The multi-core processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-8.

Images