Cpu affinity scheduling method, apparatus, device, medium and android system

Abstract

The application discloses a CPU affinity scheduling method, device, equipment, medium and an Android system. The method comprises the following steps: acquiring an application process to be run; in the case that the application process is a foreground starting process, calling a Java native interface to transmit a process number of the foreground starting process to a native layer; after a target mask set of a CPU performance core is constructed in the native layer, binding the process number of the foreground starting process with the target mask set of the CPU performance core; and the target mask set of the CPU performance core is used for indicating a CPU performance core range for scheduling the foreground starting process. By binding the foreground starting process with the mask set of the CPU performance core, the application can ensure that the foreground starting process of the application process is preferentially scheduled to execute on the CPU performance core, thereby improving system response speed and user experience.

Description

Technical Field

[0001] This application relates to the field of terminal technology, specifically to a CPU affinity scheduling method, apparatus, device, medium, and Android system. Background Technology

[0002] Currently, mobile devices generally employ a heterogeneous architecture of CPU performance cores and CPU efficiency cores. The CPU performance core resources of electronic devices are limited, and numerous background processes, such as push services and location services, continuously consume CPU performance core runtime slices. When an application process is in the foreground startup phase, the Completely Fair Scheduler (CFS) may not obtain sufficient process execution data, easily allocating foreground processes to CPU efficiency cores. Due to insufficient computing power in the CPU efficiency cores, this can easily lead to application startup lag, dropped frames, and a degraded user experience. Summary of the Invention

[0003] This invention provides a CPU affinity scheduling method, apparatus, device, medium, and Android system, aiming to solve the problem of poor user experience caused by foreground startup processes being assigned to CPU energy efficiency cores.

[0004] Firstly, a CPU affinity scheduling method is provided, including: Get the application processes to be run; When the application process is a foreground process, the Java native interface is called to transmit the process ID of the foreground process to the native layer; After constructing the target mask set of CPU performance cores at the native layer, the process ID of the foreground startup process is bound to the target mask set of CPU performance cores; the target mask set of CPU performance cores is used to indicate the range of CPU performance cores scheduled for the foreground startup process.

[0005] In some embodiments of this application, when the application process is a foreground startup process, before calling the Java native interface to transmit the process ID of the foreground startup process to the native layer, the method further includes: reading the process type of the application process from the process management list; when the process type of the application process is a foreground top-level page type or is about to become a foreground top-level page type, determining the application process as a foreground startup process; wherein, the foreground startup process is the foreground startup process of the application process of the Android system.

[0006] In some embodiments of this application, constructing a target mask set for CPU performance cores in the native layer includes: creating a CPU performance core mask structure in the native layer; the CPU performance core mask structure is used to store the initial mask set for CPU performance cores; after initializing the initial mask set, the performance core number to be bound is written to obtain the target mask set for CPU performance cores.

[0007] In some embodiments of this application, binding the process ID of the foreground startup process with the target mask set of the CPU performance core includes: sending the target mask set of the CPU performance core to the operating system kernel, and binding the process ID of the foreground startup process with the target mask set of the CPU performance core.

[0008] In some embodiments of this application, after binding the process ID of the foreground startup process with the target mask set of CPU performance cores, the method further includes: updating the task descriptor of the foreground startup process based on the target mask set by the operating system kernel; the task descriptor is used to store the CPU performance core ID that allows the foreground startup process to be scheduled to run.

[0009] In some embodiments of this application, after constructing a target mask set for CPU performance cores in the native layer, the process number of the foreground startup process is bound to the target mask set for CPU performance cores. The method further includes: when the scheduler schedules the foreground startup process, the foreground startup process is run within the range of the CPU performance core number recorded in the task descriptor.

[0010] Secondly, a CPU affinity scheduling device is provided, comprising: The acquisition module is used to acquire application processes to be run. The transmission module is used to transmit the process ID of the foreground process to the native layer by calling the Java native interface when the application process is a foreground process. The binding module is used to bind the process ID of the foreground startup process to the target mask set of CPU performance cores after the target mask set of CPU performance cores is built in the native layer; the target mask set of CPU performance cores is used to indicate the range of CPU performance cores scheduled for the foreground startup process.

[0011] Thirdly, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program or instructions, and when the computer program or instructions are executed by the processor, the processor performs the steps of the CPU affinity scheduling method as described in the first aspect.

[0012] Fourthly, a computer-readable storage medium is provided having a computer program or instructions stored thereon, which, when executed by a processor, implement the steps of the CPU affinity scheduling method as described in the first aspect.

[0013] Fifthly, an Android system is provided, including a controller for performing steps in the CPU affinity scheduling method as described in the first aspect.

[0014] In summary, the CPU affinity scheduling method provided in this application obtains the application process to be run; when the application process is a foreground process, it calls a Java native interface to transmit the process ID of the foreground process to the native layer; after constructing a target mask set for CPU performance cores in the native layer, it binds the process ID of the foreground process to the target mask set for CPU performance cores; the target mask set for CPU performance cores is used to indicate the range of CPU performance cores scheduled for the foreground process. Based on this, by binding the foreground process to the mask set for CPU performance cores, this application can ensure that the foreground process of the application is preferentially scheduled to be executed on CPU performance cores, thereby improving system response speed and user experience. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a flowchart illustrating a CPU affinity scheduling method provided in an embodiment of this application; Figure 2 This is a schematic diagram illustrating a process for binding a foreground application process to a CPU performance core, as provided in an embodiment of this application. Figure 3 This is a schematic diagram illustrating the results of a process execution test provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a CPU affinity scheduling device provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0018] In the description of the embodiments of this application, it should be understood that the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, features defined with "first" and "second" may explicitly or implicitly include one or more of the stated features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0019] The use of "applies to" or "configured to" in this application implies open and inclusive language, which does not exclude the applicability to or configuration to devices performing additional tasks or steps. Additionally, the use of "based on" implies openness and inclusivity, because processes, steps, calculations, or other actions "based on" one or more of the stated conditions or values ​​may in practice be based on additional conditions or values ​​beyond those stated.

[0020] In this application, the term "exemplary" is used to mean "used as an example, illustration, or description." Any embodiment described as "exemplary" in this application is not necessarily to be construed as being more preferred or advantageous than other embodiments. The following description is provided to enable any person skilled in the art to make and use this application. Details are set forth in the following description for purposes of explanation. It should be understood that those skilled in the art will recognize that this application can be made without using these specific details. In other instances, well-known structures and processes are not described in detail to avoid obscuring the description of this application with unnecessary detail. Therefore, this application is not intended to be limited to the embodiments shown, but is consistent with the broadest scope of the principles and features disclosed in this application.

[0021] CPU performance cores (also known as big cores) refer to CPU cores that undertake high-load, high-computation-intensity tasks. Compared to CPU energy efficiency cores, they have stronger computing power and higher operating frequencies, enabling them to quickly process computationally intensive tasks, meet the speed requirements of scenarios such as foreground application process startup and interface interaction, and ensure smooth system operation.

[0022] CPU efficiency cores (also known as small cores) refer to CPU cores that undertake low-load, lightweight background tasks. Compared to CPU performance cores, they have lower power consumption and operating frequency, and are suitable for persistent processes that do not require high computing power, such as push services, location updates, and data synchronization. While ensuring the operation of basic system functions, they can effectively extend the device's battery life.

[0023] In related technologies, the number of CPU performance cores (big cores) on low-end devices is very limited, but the number of background resident processes is relatively large. Push services, location updates, and various resident application processes each occupy relatively few CPU cycles, but these processes reside in the background for extended periods, accumulating and continuously consuming the available runtime slices of the big cores. When a user clicks the application icon to launch the application, the new foreground process has not yet accumulated corresponding runtime history data. At this time, the scheduler tends to allocate this foreground process to a CPU efficiency core (small core) with a lower load to ensure load balancing across core queues. The application's main thread then completes layout loading, resource initialization, and first frame rendering on the small core. However, the computing power of the small core is insufficient to support these operations in a short time, ultimately leading to application startup stuttering and dropped frame rates.

[0024] To at least partially address one or more of the aforementioned problems and other potential issues, this application proposes a CPU affinity scheduling method. This method includes: obtaining the application process to be run; if the application process is a foreground process, calling a Java native interface to transmit the process ID of the foreground process to the native layer; after constructing a target mask set for CPU performance cores in the native layer, binding the process ID of the foreground process to the target mask set for CPU performance cores; the target mask set for CPU performance cores is used to indicate the range of CPU performance cores scheduled for the foreground process. Based on this, by binding the foreground process to the mask set for CPU performance cores, this application can ensure that the foreground process of an application is preferentially scheduled to execute on CPU performance cores, thereby improving system response speed and user experience.

[0025] This application provides a CPU affinity scheduling method. Figure 1 This is a flowchart illustrating a CPU affinity scheduling method provided in an embodiment of this application, as shown below. Figure 1 As shown, the process of this method includes: S101: Obtain the application process to be run; S102: When the application process is a foreground process, call the Java native interface to transmit the process ID of the foreground process to the native layer; S103: After constructing the target mask set of CPU performance cores in the native layer, bind the process ID of the foreground startup process to the target mask set of CPU performance cores.

[0026] In some embodiments, the application process to be run refers to the application process corresponding to a user-initiated startup operation (such as clicking a desktop icon, restoring from the recent task list, etc.), or a process that the system is about to place in the foreground top-level page due to interaction requirements. The application process to be run is one that has not yet completed initialization or first frame rendering, is in the critical path stage of startup, and has high requirements for CPU computing power.

[0027] In some embodiments, a foreground startup process refers to an application process that is actively started by the user, needs to run on the top-level interface in the foreground, and is in the initialization to first frame rendering startup phase. It is different from background service processes and has higher requirements for running response speed.

[0028] In some embodiments, the Java Native Interface (JNI) serves as a bridge connecting application-layer Java code with underlying C / C++ native code in the Android system. JNI securely and efficiently transmits application process information (such as process ID) running at the Android framework layer to the native layer, enabling CPU affinity scheduling control at a lower level of the operating system. It should be noted that the Java Native Interface call process adheres to Android's security mechanisms and process isolation policies, ensuring that access to and manipulation of the target process's scheduling attributes are only permitted within authorized scopes.

[0029] In some embodiments, the process ID (PID) of a foreground process refers to a unique identifier (Process ID, PID) assigned to it by the operating system. This identifier is used to accurately identify and locate the target process in the kernel scheduler. The PID of a foreground process is dynamically generated by the Android system when the application process is created and remains unchanged throughout the process's lifecycle. It is a key basis for implementing process-level resource binding and scheduling control.

[0030] In some embodiments, the native layer refers to the C / C++ runtime environment on top of the Linux kernel in the Android system architecture, which includes core system services, a hardware abstraction layer, and performance-sensitive modules. Thus, by constructing a target mask set for CPU performance cores at the native layer, the scheduling latency of the application framework layer can be bypassed, allowing direct interaction with the kernel scheduling subsystem and ensuring the timely implementation of affinity policies.

[0031] In some embodiments, the target mask set for CPU performance cores is a set of CPU core availability represented as a bitmask, where each bit corresponds to a physical CPU core, and setting a bit (bit=1) indicates that the core is allowed to be scheduled to execute the target process. For example, in an eight-core heterogeneous processor, if the performance cores are CPU4-CPU7, the target mask can be represented as 0b11110000 (hexadecimal 0xF0). This mask set is distributed to the operating system kernel at the native layer by calling the sched_setaffinity system call or an equivalent kernel interface, thereby restricting foreground processes to run only on designated performance cores.

[0032] Please see Figure 2To accurately identify the application process to be run, the operating system can read the target application process's status information from the process management list (ProcessList) maintained by the ActivityManagerService in the Android framework layer. This status information can include its component type, window hierarchy attributes, and lifecycle stage. The component type is parsed; if the application process's component type is HOSTING_TYPE_TOP_ACTIVITY or HOSTING_TYPE_NEXT_TOP_ACTIVITY, the process is marked as a foreground process. The process ID (PID) of the foreground process is passed from the Java framework layer to the operating system's Native Layer via the bindPidToCore method called through JNI. The Native Layer code declares the cpu_set_t variable, initializes it using CPU_ZERO, and then adds the large core number (typically CPU 4 to 7 on an eight-core platform) to the mask using CPU_SET. The scheduling control module constructs a target mask set for the CPU performance cores based on the device hardware topology information. For example, in a specific implementation, the target mask set can be represented in bitmap form, with each bit corresponding to a physical CPU performance core. The set bits explicitly indicate the range of CPU performance cores that the foreground process is allowed to run on. After constructing the target mask set of CPU performance cores at the native layer, the system calls the kernel-provided `sched_setaffinity` system call or equivalent interface to bind the PID of the foreground process to the target mask set. After the operating system kernel completes the target mask binding, it updates the `cpus_allowed` field in the task descriptor (`task_struct`) of the foreground process's task structure, which stores the number of CPU performance cores that the foreground process is allowed to run on. Thereafter, regardless of how the Completely Fair Scheduler evaluates load balancing, subsequent scheduling of the foreground process is strictly limited to the specified performance core range, ensuring that its critical initialization operations (such as view loading, resource loading, and main thread message processing) receive sufficient high-performance computing resources, effectively avoiding startup delays and UI stuttering caused by misscheduling to energy-efficient cores. Building the target mask set for CPU performance cores at the native layer involves: identifying the CPU topology of the current device; and creating a bitmask structure, where each bit corresponds to a physical CPU core. If the bit is set to 1, it indicates that the corresponding core belongs to the allowed scheduling target range. For example, in an eight-core device with four performance cores (numbered 0-3) and four energy efficiency cores (numbered 4-7), the target mask set can be represented as 0xF0 (binary 11110000), explicitly limiting the foreground startup process to run only on cores 4 to 7.

[0033] Furthermore, after the target mask set is sent to the operating system kernel, the kernel scheduler updates the `cpus_allowed` field in the corresponding process's task descriptor (`task_struct`) based on this target mask set. The `cpus_allowed` field is a key data structure in the Linux kernel used to control process CPU affinity. The scheduler strictly adheres to the CPU set defined by this field during subsequent task scheduling to ensure that foreground processes are not incorrectly migrated to energy-efficient CPUs for execution.

[0034] It should be noted that the solution proposed in this application fully considers system compatibility and resource overhead during its implementation. The binding operation only takes effect during the critical window period when the application is launched in the foreground, avoiding unnecessary scheduling restrictions on non-critical processes. At the same time, the construction and binding of the target mask set are implemented in the system service permission domain, without modifying the kernel scheduler source code. It can be deployed on the standard Android system without deep kernel customization, and has good engineering feasibility.

[0035] In actual testing on low-end devices, after 450 hours of monkey stress testing, the number of system application crashes and Application Not Responding (ANR) incidents remained consistently high. Third-party Android application packages (APKs) experienced hundreds of ANR incidents, accounting for the highest proportion of all exceptions. After prolonged device operation, the main thread of the foreground application repeatedly encountered blocking issues, eventually leading to system termination of the corresponding process. CFS's scheduling of the foreground process to run on smaller cores is the direct cause of these problems: when the main thread performs layout calculations or resource loading, the time consumed by Binder call responses, input event handling, and synchronization lock releases significantly increases. Input event timeouts trigger the ANR mechanism; if the Binder also times out at this time, the system service throws an exception and terminates the application process. This application establishes a deterministic binding relationship between the foreground startup process and the large core during the process startup phase, eliminating the problem of insufficient processing resources caused by the initial allocation of small cores. With the main thread running on the large core, message queue processing is faster. The reduced waiting time for events transmitted by InputDispatcher and lifecycle callbacks of ActivityManagerService, along with decreased cross-process response latency in Binder, leads to fewer input event ANR (Application Not Responding) events. Simultaneously, the higher execution speed of large-core instructions shortens the execution time of synchronized code blocks, narrows the window for multi-threaded lock contention, and reduces watchdog timeouts that kill processes. Test data shows a significant decrease in ANR and crash counts. Although some system-level ANRs increased due to fluctuations in test scenarios, overall stability issues related to foreground applications showed a convergence trend, reflecting a substantial enhancement of the main thread's processing power by the core-binding mechanism. Figure 3 This is a schematic diagram illustrating the results of a process execution test provided in an embodiment of this application, such as... Figure 3 As shown, version 0627 is the version without the core binding modification, while version 0717 is the version with the core binding modification and integration. After more than 450 hours of Monkey stability stress testing, neither version of the system experienced any serious system-level failures. A horizontal comparison was made after converting the test data according to the prototype and test duration coefficients: the number of anomalies in customer-customized applications remained unchanged, while crashes in Google native applications slightly deteriorated; crashes and unresponsiveness issues in general applications and third-party applications all improved to varying degrees, and anomalies caused by main thread blocking in foreground applications were effectively suppressed. This proves that the CPU performance core binding scheduling strategy for foreground processes in this solution can alleviate the problem of excessive main thread task processing time, reduce ANR and application crashes, and optimize the long-term reliability of the system.

[0036] Through the above mechanism, even in scenarios with high system load and background processes occupying a large amount of performance core time slices, newly launched foreground applications can still obtain high-performance computing resources first by virtue of the pre-bound affinity mask, avoiding being incorrectly allocated to energy efficiency cores due to missing initial information from the scheduler, and effectively ensuring the smoothness and response speed during the startup phase.

[0037] The solution in this application embodiment obtains the application process to be run; if the application process is a foreground process, it calls a Java native interface to transmit the process ID of the foreground process to the native layer; after constructing a target mask set for CPU performance cores in the native layer, it binds the process ID of the foreground process to the target mask set for CPU performance cores; the target mask set for CPU performance cores is used to indicate the range of CPU performance cores scheduled for the foreground process. Based on this, by binding the foreground process to the mask set for CPU performance cores, this application can ensure that the foreground process of the application is preferentially scheduled to be executed on CPU performance cores, thereby improving system response speed and user experience.

[0038] In this embodiment of the disclosure, when the application process is a foreground startup process, before calling the Java native interface to transmit the process ID of the foreground startup process to the native layer, the method further includes: reading the process type of the application process from the process management list; when the process type of the application process is a foreground top-level page type or is about to become a foreground top-level page type, determining the application process as a foreground startup process; wherein, the foreground startup process is the foreground startup process of the application process of the Android system.

[0039] In some embodiments, the process management list refers to the management list maintained in the Android system's ActivityManagerService to record the status and attributes of all launched application processes. It records key information such as the component type, window level, and lifecycle stage of each process, providing data support for accurately identifying foreground launched processes.

[0040] In some embodiments, the process type of an application process refers to the process attribute category categorized by ActivityManagerService based on the functionality of the components carried by the process. Different categories correspond to different system resource scheduling priorities and running scenarios. Thus, by matching the category identifier, the target process that needs to be bound to the performance core can be quickly filtered out without the need for complex UI hierarchy traversal detection, reducing the time overhead of the identification process.

[0041] In some embodiments, the foreground top-level page type (HOSTING_TYPE_TOP_ACTIVITY) refers to the application process type that is currently running in the foreground top-level interface, needs to interact with the user, and is the highest priority.

[0042] In some embodiments, the HOSTING_TYPE_NEXT_TOP_ACTIVITY type that is about to become the foreground top-level page refers to the application process type that has completed startup preparation and is about to switch to the foreground top-level interface. This type of process also has high requirements for response speed and needs to allocate high-performance resources in advance to ensure the smoothness of subsequent switching.

[0043] In some embodiments, Android refers to an open-source mobile operating system built on the Linux kernel. Its architecture includes an application layer, a framework layer, a native layer, and a kernel layer, supporting multi-process concurrency and heterogeneous computing resource scheduling. Thus, Android works in collaboration with the Native layer through ActivityManagerService to accurately identify foreground processes and bind them to high-performance cores without modifying the kernel source code, thereby optimizing system response performance on critical paths.

[0044] In this embodiment of the disclosure, constructing a target mask set for CPU performance cores in the native layer includes: creating a CPU performance core mask structure in the native layer; the CPU performance core mask structure is used to store the initial mask set for CPU performance cores; after initializing the initial mask set, the performance core number to be bound is written to obtain the target mask set for CPU performance cores.

[0045] In some embodiments, the CPU performance core mask structure refers to a data structure defined in the native layer, used to encapsulate and manage the bitmask information of the CPU performance cores. Internally, it typically contains a bitmap array or integer variable aligned with the number of CPUs in the system, supporting bitwise operations to dynamically set or clear the availability state of specific cores. The CPU performance core mask structure is created during the initialization of the scheduling control module and filled with an initial mask set based on the actual heterogeneous CPU topology of the device, ensuring that only the bits corresponding to the performance cores are set to 1, while the remaining bits remain 0, thereby providing an accurate hardware mapping basis for subsequent affinity binding.

[0046] In some embodiments, the initial mask set for CPU performance cores refers to the initial bitmask generated based on the CPU core topology information preset by the device. In the initial state, the bits corresponding to all performance cores are set by default, and the bits corresponding to energy efficiency cores are cleared to zero. There is no need to dynamically traverse and detect the core type at runtime, which can quickly generate a target mask that conforms to the hardware configuration and reduce the time overhead of the mask construction process.

[0047] In some embodiments, the performance core number to be bound refers to a set of physical core identifiers used to perform high-performance tasks, which are predefined or dynamically detected by the system based on the heterogeneous CPU architecture of the current device. These typically correspond to specific core numbers within a CPU performance core (large core) or performance cluster. The performance core number to be bound can be determined at system startup by parsing the topology information in the / sys / devices / system / cpu / directory or reading the performance core markers in the Device Tree. This information is then written into the CPU performance core mask structure as the basis for constructing the target mask set, ensuring that the foreground startup process is only scheduled to run on cores with high clock speeds and strong computing capabilities.

[0048] In this way, by creating a CPU performance core mask structure at the native layer, initializing the initial mask set, and writing the performance core number to be bound, the target mask set of the CPU performance core is obtained. This can accurately match the CPU hardware architecture of the current device, without having to repeatedly detect the core type every time the process starts. It can quickly generate a target mask set that matches the hardware configuration, which not only ensures the accuracy of affinity settings, but also reduces the time overhead of scheduling operations and will not cause additional delays to the application startup process.

[0049] In this embodiment of the disclosure, binding the process ID of the foreground startup process with the target mask set of the CPU performance core includes: sending the target mask set of the CPU performance core to the operating system kernel, and binding the process ID of the foreground startup process with the target mask set of the CPU performance core.

[0050] In some embodiments, the operating system kernel refers to the core system layer of the Android system based on the Linux kernel. It is responsible for hardware resource management and process scheduling, and provides the sched_setaffinity standard system call interface for setting the CPU affinity of a process. This call interface can directly pass the target mask generated in user space into the kernel to update the process scheduling range. The function can be implemented without additional modification to the kernel code and is compatible with most mainstream Android versions.

[0051] In this way, by sending the target mask set of CPU performance cores to the operating system kernel and binding the process ID of the foreground startup process to the target mask set of CPU performance cores, it can be ensured that the foreground startup process is strictly limited to the specified performance core set during subsequent scheduling, thus ensuring the high-priority execution requirements of the foreground application startup phase when system resource competition is fierce.

[0052] In this embodiment of the disclosure, after binding the process ID of the foreground startup process with the target mask set of CPU performance cores, the method further includes: updating the task descriptor of the foreground startup process based on the target mask set by the operating system kernel; the task descriptor is used to store the CPU performance core ID that allows the foreground startup process to be scheduled and run.

[0053] In some embodiments, the task descriptor of a foreground process refers to the `cpus_allowed` field contained in the `task_struct` structure in the Linux kernel. This field precisely records the set of CPU cores on which the current process is allowed to run, in the form of a bitmask. When the `sched_setaffinity` system call executes successfully, the kernel atomically writes the passed target mask into this field and triggers the scheduler to re-evaluate the schedulable range of the process. Thereafter, regardless of how the load balancing mechanism migrates tasks, the scheduler strictly verifies the `cpus_allowed` field when selecting a run queue, ensuring that the foreground process is only awakened and executed on preset performance cores, thereby solidifying its high-performance resource access permissions at the hardware level.

[0054] In this way, by updating the task descriptor of the foreground startup process based on the target mask set by the operating system kernel, the running position of the process can be forcibly constrained in the underlying mechanism of scheduling decision, so as to avoid performance core deviation caused by scheduler heuristic strategy or load balancing migration, and ensure that the foreground startup process always obtains the optimal computing resources during the critical initialization phase of its life cycle.

[0055] In this embodiment of the disclosure, after constructing the target mask set of CPU performance cores in the native layer, the process number of the foreground startup process is bound to the target mask set of CPU performance cores. The method further includes: when the scheduler schedules the foreground startup process, the foreground startup process is run within the range of the CPU performance core number recorded in the task descriptor.

[0056] In some embodiments, the scheduler refers to the Completely Fair Scheduler (CFS) or its real-time variant in the Linux kernel. When scheduling tasks, the scheduler actively queries the `cpus_allowed` field in the `task_struct` and only places foreground processes into the run queue corresponding to the performance core specified by this field. When selecting a target CPU to execute the process, the scheduler skips all cores that are not explicitly set, even if these cores are currently idle, thus ensuring that the process is not migrated to an energy-efficient core due to local load balancing or power-saving strategies.

[0057] In this way, by scheduling the foreground startup process according to the CPU performance core number recorded in the task descriptor, the foreground startup process can be run within the range of CPU performance core numbers. This can completely avoid the problem of the foreground startup process being incorrectly assigned to the CPU energy efficiency core, and ensure that the application always runs on the CPU core with stronger performance during the critical interactive stage of startup, thus stably guaranteeing the application startup speed and the smoothness of the interface interaction response.

[0058] This application provides a CPU affinity scheduling device. Figure 4 This is a schematic diagram of the structure of a CPU affinity scheduling device provided in an embodiment of this application, as shown below. Figure 4 As shown, the device includes: Module 401 is used to obtain the application process to be run; The transmission module 402 is used to transmit the process ID of the foreground process to the native layer by calling the Java native interface when the application process is a foreground process. Binding module 403 is used to bind the process ID of the foreground startup process to the target mask set of CPU performance cores after the target mask set of CPU performance cores is constructed in the native layer; the target mask set of CPU performance cores is used to indicate the range of CPU performance cores scheduled for the foreground startup process.

[0059] Based on any of the above embodiments, another embodiment of this application also provides an electronic device, such as... Figure 5 As shown, the electronic device may include a processor 510, a communications interface 520, a memory 530, and a communications bus 540, wherein the processor 510, the communications interface 520, and the memory 530 communicate with each other through the communications bus 540. The processor 510 can call logical instructions in the memory 530 to execute the CPU affinity scheduling method described above.

[0060] Furthermore, when the computer program or instructions in the aforementioned memory 530 can be implemented as a software functional unit and sold or used as an independent product, 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 part 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 an electronic 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 a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0061] The above-described device embodiments are merely illustrative. The units described as separate components may or may not be physically separate, and 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 modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0062] This application provides an Android system including a controller for performing steps in the CPU affinity scheduling method as described in the first aspect.

[0063] The foregoing has provided a detailed description of a CPU affinity scheduling method, apparatus, device, medium, and Android system provided in the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A CPU affinity scheduling method, characterized in that, include: Get the application processes to be run; If the application process is a foreground process, the Java native interface is called to transmit the process ID of the foreground process to the native layer; After constructing the target mask set for CPU performance cores in the native layer, the process ID of the foreground startup process is bound to the target mask set for CPU performance cores; the target mask set for CPU performance cores is used to indicate the range of CPU performance cores scheduled for the foreground startup process.

2. The method according to claim 1, characterized in that, Before calling the Java native interface to transmit the process ID of the foreground process to the native layer when the application process is a foreground process, the method further includes: Read the process type of the application process from the process management list; If the process type of the application process is a foreground top-level page type or is about to become a foreground top-level page type, the application process is identified as the foreground startup process; The foreground startup process is the foreground startup process of the application process in the Android system.

3. The method according to claim 1, characterized in that, The target mask set for constructing CPU performance cores in the native layer includes: A CPU performance core mask structure is created in the native layer; the CPU performance core mask structure is used to store the initial mask set of the CPU performance core; After initializing the initial mask set, the performance core number to be bound is written in to obtain the target mask set of the CPU performance core.

4. The method according to claim 1, characterized in that, The step of binding the process ID of the foreground startup process with the target mask set of the CPU performance cores includes: The target mask set of the CPU performance core is sent to the operating system kernel, and the process ID of the foreground startup process is bound to the target mask set of the CPU performance core.

5. The method according to claim 4, characterized in that, After binding the process ID of the foreground startup process to the target mask set of the CPU performance cores, the method further includes: The operating system kernel updates the task descriptor of the foreground startup process based on the target mask set; the task descriptor is used to store the CPU core number that allows the foreground startup process to be scheduled to run.

6. The method according to claim 5, characterized in that, After constructing the target mask set for CPU performance cores in the native layer, the method further includes binding the process ID of the foreground startup process to the target mask set for CPU performance cores. When the scheduler schedules the foreground startup process, the foreground startup process runs within the range of CPU performance core numbers recorded in the task descriptor.

7. A CPU affinity scheduling device, characterized in that, include: The acquisition module is used to acquire application processes to be run. The transmission module is used to transmit the process ID of the foreground process to the native layer by calling the Java native interface when the application process is a foreground process. The binding module is used to bind the process ID of the foreground startup process to the target mask set of CPU performance cores after the target mask set of CPU performance cores is constructed in the native layer; the target mask set of CPU performance cores is used to indicate the range of CPU performance cores scheduled for the foreground startup process.

8. An electronic device, characterized in that, It includes a memory and a processor, wherein the memory stores a computer program or instructions, which, when executed by the processor, cause the processor to perform the steps in the CPU affinity scheduling method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, It stores computer programs or instructions that, when executed by a processor, implement the steps of the CPU affinity scheduling method as described in any one of claims 1 to 6.

10. An Android system, characterized in that, Includes a controller for performing the steps in the CPU affinity scheduling method as described in any one of claims 1 to 6.

Images