Task submission method, electronic device and storage medium

Abstract

The present application provides a task submission method, an electronic device and a storage medium. In this method, an asynchronous task generated by a user-mode process is directly submitted to a kernel thread bound to a CPU core, and the asynchronous task is executed by the kernel thread. This method solves the problem that a CPU core cannot be selected when submitting a task based on a non-core-bound work queue, and realizes the scheduling optimization of asynchronous tasks.

Description

Technical Field

[0001] The present application relates to the field of intelligent terminal technology, and in particular to a task submission method, an electronic device and a storage medium. Background Art

[0002] Workqueue is a task scheduling mechanism in the Linux kernel that can be used to process asynchronous tasks. The workqueue mechanism allows asynchronous tasks to be placed in the workqueue and wait for the system to be idle for task scheduling and execution.

[0003] Among them, the work queue corresponds to one or more worker thread pools (worker-pool), and each worker thread (or kernel thread) in the worker thread pool will continuously obtain tasks to be executed from the work queue and execute tasks on different CPU (Central Processing Unit) cores.

[0004] However, when the work queue is not bound to a core, the priorities of the worker threads (worker_thread) in the corresponding work thread pool are the same, and it is uncontrollable which CPU core each worker thread runs on, which may cause high delays in scheduling some tasks. Summary of the invention

[0005] In order to solve the above technical problems, the present application provides a task submission method, an electronic device and a storage medium. In the method, the submission mode of the asynchronous task is modified to achieve the scheduling optimization of the asynchronous task.

[0006] In a first aspect, an embodiment of the present application provides a task submission method. The method is applied in an electronic device, comprising:

[0007] The electronic device creates a target working thread and binds the target working thread to a target CPU core; the electronic device obtains a target asynchronous task generated by a target user-mode process; the electronic device submits the target asynchronous task to the target working thread, and the target working thread executes the target asynchronous task; wherein the target working thread is created and bound to the target CPU core during the power-on phase of the electronic device.

[0008] The target CPU core may be any CPU core of the electronic device, including but not limited to a large CPU core, a medium CPU core, and a small CPU core.

[0009] In this way, the asynchronous task generated by the user-mode process is directly submitted to the kernel thread bound to a CPU core, and the asynchronous task is executed through the kernel thread, which solves the problem of not being able to select the CPU core when submitting tasks based on a non-core-bound work queue, and realizes the scheduling optimization of asynchronous tasks.

[0010] According to the first aspect, the electronic device creates a target working thread and binds the target working thread to the core of the target CPU. Specifically, during the power-on phase of the electronic device, the electronic device creates a target working thread and binds the target working thread to the core of the target CPU.

[0011] According to the first aspect, or any implementation of the first aspect above, the electronic device includes multiple CPU cores, and among the multiple CPU cores, the frequency of the first CPU core is the lowest.

[0012] In one example, the first CPU core is a small CPU core among multiple CPU cores.

[0013] According to the first aspect, or any implementation method of the first aspect above, the electronic device creates a target working thread and binds the target working thread to the target CPU core, including: the electronic device creates a real-time working thread and binds the real-time working thread to the first CPU core; the electronic device submits the target asynchronous task to the target working thread, and the target working thread executes the target asynchronous task, including: when the target user state process belongs to the foreground process group, the target asynchronous task is submitted to the real-time working thread, and the real-time working thread executes the target asynchronous task.

[0014] In this way, the asynchronous tasks generated by the foreground process are directly submitted to the real-time thread bound to the first CPU core (such as the small CPU core) for execution. Since the first CPU core is relatively idle, the real-time thread can also obtain the running right of the first CPU core more quickly, so that the asynchronous tasks can be executed earlier, avoiding the problem of high task scheduling delay, and thus solving the problem of foreground process jams, improving the user experience.

[0015] According to the first aspect, or any implementation of the first aspect above, the multiple CPU cores further include at least one second CPU core, at least one third CPU core, and at least one fourth CPU core;

[0016] The frequency of the second CPU core is the same as that of the first CPU core, the frequency of the second CPU core is lower than the frequency of the third CPU core, and the frequency of the third CPU core is lower than the frequency of the fourth CPU core.

[0017] In one example, the second CPU core is a small CPU core among the multiple CPU cores, the third CPU core is a medium CPU core among the multiple CPU cores, and the fourth CPU core is a large CPU core among the multiple CPU cores.

[0018] According to the first aspect, or any implementation method of the first aspect above, the electronic device creates a target working thread and binds the target working thread to the target CPU core, including: the electronic device also creates multiple ordinary working threads, and binds the multiple ordinary working threads to the second CPU core, the third CPU core, and the fourth CPU core respectively; the electronic device submits the target asynchronous task to the target working thread, and the target working thread executes the target asynchronous task, including: when the target user state process belongs to a non-foreground process group, submits the target asynchronous task to an ordinary working thread bound to the second CPU core or the third CPU core or the fourth CPU core, and an ordinary working thread executes the target asynchronous task.

[0019] In this embodiment, for asynchronous tasks generated by non-foreground processes, they are directly submitted to ordinary threads bound to the second CPU core, the third CPU core, or the fourth CPU core (such as a small CPU core, a medium CPU core, or a large CPU core) for execution, thereby solving the problem of not being able to select the CPU core on which the work thread runs when submitting tasks based on a non-core-bound work queue, and reducing the delay in task scheduling.

[0020] According to the first aspect, or any implementation of the first aspect above, the method further includes:

[0021] The electronic device sets the priority of each ordinary working thread according to the type of CPU core to which the ordinary working thread is bound; wherein, the priority of the ordinary working thread bound to the second CPU core is higher than the priority of the ordinary working thread bound to the third CPU core, and the priority of the ordinary working thread bound to the third CPU core is higher than the priority of the ordinary working thread bound to the fourth CPU core.

[0022] In this implementation, the higher the frequency of the CPU core, the lower the priority of the ordinary worker thread bound to it. This allows the ordinary worker thread used to execute asynchronous tasks to run on a CPU core with a lower frequency, that is, to run on a CPU core with lower competition, and try to avoid competing for resources with other threads, so as to obtain the running right of the CPU core as soon as possible.

[0023] According to the first aspect, or any implementation of the first aspect above, the electronic device submits the target asynchronous task to an ordinary working thread bound to the second CPU core or the third CPU core or the fourth CPU core, including: the electronic device selects an ordinary working thread from multiple ordinary working threads according to the priority of each ordinary working thread, and submits the target asynchronous task to an ordinary working thread.

[0024] In this way, for an asynchronous task generated by a non-foreground process, a common working thread for executing the asynchronous task can be selected based on the thread priority, so that the asynchronous task can be scheduled for execution as soon as possible.

[0025] According to the first aspect, or any implementation of the first aspect above, after creating the target working thread, the method also includes: the electronic device allocates a thread pointer to the target working thread; wherein the thread pointer, that is, the RCU protection pointer mentioned below, is a pointer protected based on the RCU mechanism, and the value of the thread pointer is used to point to the address of the target working thread.

[0026] Since asynchronous tasks need to be submitted to working threads on different CPU cores for processing, concurrent protection of thread pointers of each working thread is implemented based on the RCU mechanism, which can solve the concurrent security problem of asynchronous tasks submitted by multiple user processes.

[0027] According to the first aspect, or any implementation method of the first aspect above, the electronic device submits the target asynchronous task to the target working thread, including: the electronic device obtains the thread pointer value of the target working thread based on the RCU mechanism; the electronic device submits the target asynchronous task to the target working thread according to the thread pointer value of the target working thread.

[0028] According to the first aspect, or any implementation of the first aspect above, the asynchronous task includes a data reading task or a data updating task for the file system.

[0029] According to the first aspect, or any implementation of the first aspect above, the target asynchronous task is a task that needs to be submitted to a work queue in a native mechanism of the Linux kernel, and the work queue is not bound to a CPU core.

[0030] In a second aspect, an embodiment of the present application provides an electronic device. The electronic device includes: one or more processors; a memory; and one or more computer programs, wherein the one or more computer programs are stored in the memory, and when the computer programs are executed by the one or more processors, the electronic device executes the first aspect and any one of the task submission methods in the first aspect.

[0031] The second aspect and any implementation of the second aspect correspond to the first aspect and any implementation of the first aspect respectively. The technical effects corresponding to the second aspect and any implementation of the second aspect can refer to the technical effects corresponding to the above-mentioned first aspect and any implementation of the first aspect, which will not be repeated here.

[0032] In a third aspect, an embodiment of the present application provides a computer-readable storage medium. The computer-readable storage medium includes a computer program, and when the computer program is executed on an electronic device, the electronic device executes the task submission method of the first aspect and any one of the first aspects.

[0033] The third aspect and any implementation of the third aspect correspond to the first aspect and any implementation of the first aspect, respectively. The technical effects corresponding to the third aspect and any implementation of the third aspect can refer to the technical effects corresponding to the first aspect and any implementation of the first aspect, which will not be repeated here.

[0034] In a fourth aspect, an embodiment of the present application provides a computer program product, including a computer program, which, when executed, enables a computer to execute a task submission method as in the first aspect or any one of the first aspects.

[0035] The fourth aspect and any implementation of the fourth aspect correspond to the first aspect and any implementation of the first aspect, respectively. The technical effects corresponding to the fourth aspect and any implementation of the fourth aspect can refer to the technical effects corresponding to the above-mentioned first aspect and any implementation of the first aspect, which will not be repeated here.

[0036] In a fifth aspect, the present application provides a chip, the chip comprising a processing circuit and a transceiver pin, wherein the transceiver pin and the processing circuit communicate with each other through an internal connection path, and the processing circuit executes the task submission method as in the first aspect or any one of the first aspects to control the receiving pin to receive a signal, and to control the sending pin to send a signal.

[0037] The fifth aspect and any implementation of the fifth aspect correspond to the first aspect and any implementation of the first aspect, respectively. The technical effects corresponding to the fifth aspect and any implementation of the fifth aspect can refer to the technical effects corresponding to the first aspect and any implementation of the first aspect, which will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] Figure 1 The figure is a schematic diagram showing an example of asynchronous task submission based on workqueue;

[0039] Figure 2a The figure is a schematic diagram of a scenario of asynchronous task submission based on a non-core-bound workqueue;

[0040] Figure 2b The figure is a schematic diagram of a scheduling scenario of an asynchronous task of a foreground process shown as an example;

[0041] Figure 3 is a schematic diagram of the hardware structure of an electronic device shown as an example;

[0042] Figure 4 A schematic diagram of the software structure of an electronic device is shown as an example;

[0043] Figure 5 The figure is a schematic diagram of module interaction in the initialization phase of a working thread shown as an example;

[0044] Figure 6 A schematic diagram showing exemplary initialization and priority setting of working threads;

[0045] Figure 7 is a schematic diagram of asynchronous task scheduling shown as an example;

[0046] Figure 8a The figure is a schematic diagram of module interaction in the asynchronous task submission phase shown as an example;

[0047] Figure 8b The figure is a schematic diagram of module interaction in the asynchronous task submission phase, which is shown as an example. DETAILED DESCRIPTION

[0048] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0049] The term "and / or" in this article is merely a description of the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone.

[0050] The terms "first" and "second" in the description and claims of the embodiments of the present application are used to distinguish different objects rather than to describe a specific order of objects. For example, a first target object and a second target object are used to distinguish different target objects rather than to describe a specific order of target objects.

[0051] In the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a specific way.

[0052] In the description of the embodiments of the present application, unless otherwise specified, the meaning of "multiple" refers to two or more than two. For example, multiple processing units refer to two or more processing units; multiple systems refer to two or more systems.

[0053] Workqueue is a task scheduling mechanism in the Linux kernel that can be used to handle asynchronous tasks. Asynchronous tasks refer to tasks that enter the task queue instead of the main thread, that is, tasks that are not executed in the order of the code in the program. When the main code program executes an asynchronous task, the asynchronous task will be placed in the task queue, and the main code program will continue to execute backwards. The workqueue mechanism allows asynchronous tasks to be placed in the work queue, waiting for the system to be idle for task scheduling and execution.

[0054] Reference Figure 1 , a workqueue can be understood as a collection of tasks (or work), and a workqueue and work have a one-to-many relationship. A worker-pool is a collection of kernel threads (or worker_threads), and a worker-pool and worker_thread also have a one-to-many relationship. Pool-workqueue is the intermediary between workqueue and worker-pool, responsible for establishing the relationship between the workqueue and the worker-thread pool. The workqueue and pool-workqueue have a one-to-many relationship, and the pool-workqueue and worker-pool have a one-to-one relationship. In other words, a workqueue can correspond to one or more worker-thread pools.

[0055] Optionally, in electronic devices such as mobile phones and tablet computers, one work queue corresponds to one work thread pool, which is not limited in this embodiment. The following explanation is given by taking one work queue corresponding to one work thread pool as an example.

[0056] Continue to refer to Figure 1After the asynchronous task is submitted to the work queue, the operating system generates or selects a kernel thread from the worker-pool corresponding to the work queue, and uses the kernel thread to continuously obtain the asynchronous tasks to be executed from the work queue and execute the corresponding tasks on different CPU cores. The higher the priority of the kernel thread, the higher the priority of the kernel thread on the CPU core. It should be pointed out that in the worker-pool corresponding to a certain work queue, the priority of each kernel thread is the same.

[0057] In the Linux kernel, work queues can be divided into core-bound work queues and unbound work queues. In the core-bound work queue, or processor-bound work queue, each kernel thread created by a worker is bound to a specific CPU core to run; in the unbound work queue, or processor-unbound work queue, the wq_unbound flag needs to be specified when creating it, and each kernel thread created by a worker is not bound to a specific CPU core and can be migrated between CPU cores.

[0058] In the native mechanism of the Linux kernel, compared with the work queue bound to the core, the number of kernel threads generated in the work thread pool corresponding to the work queue not bound to the core is small, and the corresponding kernel threads will not be generated for each CPU core. For example, an electronic device includes 8 CPU cores, and the number of kernel threads generated in the work thread pool corresponding to the work queue not bound to the core may be three or four, etc. Moreover, in the work thread pool corresponding to the work queue not bound to the core, the priority of each kernel thread is the same, so it is uncontrollable which CPU core each kernel thread runs on, which may cause high task scheduling delays in some application scenarios.

[0059] For example, refer to Figure 2a As shown, among the multiple CPU cores of the electronic device, there are more processes running on the CPU7 core and the CPU6 core, and the competition is fierce. Assume that the number of kernel threads generated by the work thread pool corresponding to the unbound core work queue is small, and they all run on CPU cores with fierce competition (such as CPU7 core, CPU6 core, etc.). Since the tasks in the unbound core work queue will be submitted to the kernel threads generated by the corresponding work thread pool, when the number of tasks in the unbound core work queue increases, the tasks in the unbound core work queue will continue to be submitted to these kernel threads generated by the work thread pool, so that the number of tasks to be processed by each kernel thread increases, which will lead to the problem of increased task scheduling delays. Continue to refer to Figure 2aAmong the multiple CPU cores of an electronic device, there are relatively few processes running on CPU0 and CPU1 cores, and kernel threads can obtain the running rights of these CPU cores more quickly. However, since the tasks in the unbound core work queue are not submitted to these kernel threads, the running resources of these relatively idle CPU cores will undoubtedly be wasted.

[0060] It is understandable that the CPU core of an electronic device can be divided into a small CPU core, a medium CPU core, a large CPU core, and an ultra-large CPU core. The frequencies of the small CPU core, the medium CPU core, the large CPU core, and the ultra-large CPU core increase successively, and their operating heating problems will also increase successively. Among them, the frequency of the CPU core can be understood as the number of instructions processed per unit time. In some examples, the CPU core of an electronic device can also be divided into a small CPU core, a small CPU core, a medium CPU core, a large CPU core, and the like. Regarding the division of the CPU core, this embodiment does not limit it.

[0061] As another example, in a CPU core scheduling scenario, refer to Figure 2b As shown, among the various types of CPU cores of an electronic device, the smaller the CPU core, the fewer foreground processes are running on it, and the larger the CPU core, the more foreground processes are running on it. That is, compared with the small CPU core, more foreground processes are running on the CPU medium core and the CPU large core, and compared with the small CPU core and the CPU medium core, more foreground processes are running on the CPU large core.

[0062] Among them, the foreground process can be understood as a process that is necessary for the user's current operation. A process can be considered a foreground process if it meets any of the following conditions: it contains an Activity that is being interacted with, a Service that is bound to an Activity that is being interacted with, a Service that is running in the "foreground" (the service has called startForeground()), a Service that is executing a lifecycle callback (onCreate(), onStart(), or onDestroy()), or a BroadcastReceiver that is executing its onReceive() method.

[0063] It is understandable that the foreground process is a process involving an application program that interacts with a user, requires a higher response speed, and has a higher priority, while the background process basically does not interact with the user and has a slightly lower priority. The foreground process and the background process can be switched at any time.

[0064] In this case, after the asynchronous task generated by the foreground process is submitted to the work queue that is not bound to a core, the asynchronous task is more likely to be scheduled to the CPU core that runs more foreground processes, such as Figure 2b As shown, due to the relatively fierce competition among these CPU cores, the asynchronous task cannot be executed quickly, resulting in a high task scheduling delay, which in turn causes the electronic device to experience a freeze.

[0065] In order to solve the above problems, an embodiment of the present application provides a task submission method. In this method, kernel threads are initialized on each CPU core of an electronic device, and different priorities are set for each kernel thread according to the CPU core where the kernel thread is located. In this method, for some asynchronous tasks, they are no longer submitted to a work queue that is not bound to a core, but are submitted to a kernel thread initialized on a certain CPU core according to a preset scheduling policy, and the corresponding asynchronous tasks are executed through the kernel thread.

[0066] like Figure 3 FIG. 1 is a schematic diagram of the structure of the electronic device 100. Optionally, the electronic device 100 may be a terminal, which may also be referred to as a terminal device. The terminal may be an electronic device such as a cellular phone or a tablet computer, which is not limited in this application. It should be understood that Figure 3 The electronic device 100 shown is only one example of an electronic device, and the electronic device 100 may have more or fewer components than shown in the figure, may combine two or more components, or may have a different configuration of components. Figure 3 The various components shown in the EMBODIMENTS 2000 may be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and / or application specific integrated circuits.

[0067] The electronic device 100 may include: a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor, a gyroscope sensor, an acceleration sensor, a temperature sensor, a motion sensor, an air pressure sensor, a magnetic sensor, a distance sensor, a proximity light sensor, a fingerprint sensor, a touch sensor, an ambient light sensor, a bone conduction sensor, etc.

[0068] The processor 110 may include one or more processing units, for example, the processor 110 may include an application processor (AP), a modem processor, a graphics processor (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0069] In one implementation, the processor 110 may include a CPU, and the CPU may include multiple CPU cores. The CPU core is used for the CPU to perform data operations. Exemplarily, the CPU may include 2 CPU cores, 4 CPU cores, 8 CPU cores, 16 CPU cores, etc.

[0070] Among them, the frequencies of different CPU cores are not the same. The higher the frequency, the faster the CPU core's operating speed. Among them, the faster the operating speed can be understood as the more instructions processed per unit time. Exemplarily, according to the frequency of the CPU core, the CPU core can be divided into a CPU large core, a CPU medium core, and a CPU small core. Taking an 8-core CPU as an example, it can include one CPU large core, three CPU medium cores, and four CPU small cores.

[0071] It is understandable that the frequencies of the CPU large core, CPU medium core, and CPU small core decrease in sequence. In some examples, the CPU core of the electronic device can also be divided into CPU super large core, CPU large core, CPU medium core, CPU small core, CPU small core, etc. Regarding the division of CPU cores, this embodiment does not limit it.

[0072] The controller may be the nerve center and command center of the electronic device 100. The controller may generate an operation control signal according to the instruction operation code and the timing signal to complete the control of fetching and executing instructions.

[0073] A memory may also be provided in the processor 110 for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory.

[0074] The wireless communication function of the electronic device 100 can be implemented through the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, the modem processor and the baseband processor.

[0075] The external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 through the external memory interface 120 to implement a data storage function.

[0076] The internal memory 121 can be used to store computer executable program codes, which include instructions. The processor 110 executes various functional applications and data processing of the electronic device 100 by running the instructions stored in the internal memory 121, such as enabling the electronic device 100 to implement the task submission method in the embodiment of the present application. The internal memory 121 may include a program storage area and a data storage area. Among them, the program storage area may store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc. The data storage area may store data created during the use of the electronic device 100 (such as audio data, a phone book, etc.), etc. In addition, the internal memory 121 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc.

[0077] The software system of the electronic device 100 may adopt a layered architecture, an event-driven architecture, a micro-core architecture, a micro-service architecture, or a cloud architecture. The embodiment of the present application takes the Android system of the layered architecture as an example to exemplify the software structure of the electronic device 100.

[0078] Figure 4 It is a software structure block diagram of the electronic device 100 according to an embodiment of the present application.

[0079] The layered architecture of the electronic device 100 divides the software into several layers, each with clear roles and division of labor. The layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into four layers, from top to bottom, namely, the application layer, the application framework layer, the Android runtime (Android Runtime) and the system library, and the kernel layer.

[0080] The application layer can include a series of application packages.

[0081] like Figure 4 As shown, exemplarily, the application package may include applications such as call, calendar, map, navigation, music, video, short message, camera, gallery, etc.

[0082] The application framework layer provides an application programming interface (API) and a programming framework for the applications in the application layer. The application framework layer includes some predefined functions.

[0083] like Figure 4 As shown, the application framework layer may include a window manager, a content provider, a view system, a phone manager, a resource manager, a notification manager, and the like.

[0084] The window manager is used to manage window programs. The window manager can obtain the display screen size, determine whether there is a status bar, lock the screen, capture the screen, etc.

[0085] Content providers are used to store and retrieve data and make it accessible to applications. The data may include videos, images, audio, calls made and received, browsing history and bookmarks, phone books, etc.

[0086] The view system includes visual controls, such as controls for displaying text, controls for displaying images, etc. The view system can be used to build applications. A display interface can be composed of one or more views. For example, a display interface including a text notification icon can include a view for displaying text and a view for displaying images.

[0087] The phone manager is used to provide communication functions of the electronic device 100, such as management of call status (including connecting, hanging up, etc.).

[0088] The resource manager provides various resources for applications, such as localized strings, icons, images, layout files, video files, and so on.

[0089] The notification manager allows applications to display notification information in the status bar, which can be used to convey notification-type messages and can disappear automatically after a short stay without user interaction. For example, notification information is used to inform the completion of downloads, message reminders, etc. Notification information can also be a notification that appears in the system top status bar in the form of a chart or scroll bar text, such as a notification of an application running in the background, or a notification that appears on the screen in the form of a dialog window. Notification information can also be, for example, a text message prompted in the status bar, a prompt sound, a vibration of an electronic device, a flashing indicator light, etc.

[0090] Android Runtime includes core libraries and virtual machines. Android Runtime is responsible for scheduling and management of the Android system.

[0091] The core library consists of two parts: one part is the function that needs to be called by the Java language, and the other part is the Android core library.

[0092] The application layer and the application framework layer run in a virtual machine. The virtual machine executes the Java files of the application layer and the application framework layer as binary files. The virtual machine is used to perform functions such as object life cycle management, stack management, thread management, security and exception management, and garbage collection.

[0093] The system library may include multiple functional modules, such as surface manager, media library, 3D graphics processing library (such as OpenGL ES), 2D graphics engine (such as SGL), etc.

[0094] The surface manager is used to manage the display subsystem and provide the fusion of 2D and 3D layers for multiple applications.

[0095] The media library supports playback and recording of a variety of commonly used audio and video formats, as well as static image files, etc. The media library can support a variety of audio and video encoding formats, such as: MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc.

[0096] The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.

[0097] A 2D graphics engine is a drawing engine for 2D drawings.

[0098] The kernel layer is the layer between hardware and software. Figure 4 As shown, the kernel layer may include an initialization subsystem, a memory management subsystem, a CPU management module, a scheduling module, an RCU (Read Copy Update) module, a cgroup (controlgroup, which may be referred to as a control group) module, and a file system module.

[0099] The initialization subsystem may be used to perform initialization operations on each CPU core. Exemplarily, the initialization subsystem may be used to create a kernel thread on each CPU core and perform initialization operations on each kernel thread.

[0100] The memory management subsystem can be used to allocate and manage the memory of electronic devices.

[0101] The CPU management system can be used to manage each CPU core, such as managing the ID and other information of each CPU core.

[0102] In this embodiment, the scheduling module can be used to set the priority of the kernel thread based on the CPU core where the kernel thread is located.

[0103] The RCU module is used to provide concurrency protection for the thread pointers of kernel threads based on the RCU mechanism in the scenario where multiple kernel threads execute asynchronous tasks, thereby ensuring the concurrency safety of asynchronous tasks submitted to kernel threads.

[0104] The cgroup module can be used to determine the control group to which a user-mode process belongs, for example, to determine whether the control group to which a user-mode process belongs is the foreground process control group.

[0105] The file system module can be understood as a functional module located in the kernel layer corresponding to the file system. In this embodiment, the file system module can read the thread pointer of the kernel thread based on the RCU mechanism, and submit asynchronous tasks related to the file system (such as data reading tasks, data update tasks) to the corresponding kernel thread.

[0106] like Figure 4 As shown, the kernel layer may also include at least a display driver, an audio driver, a Wi-Fi driver, a sensor driver, etc. Among them, the hardware includes at least a processor, a display screen, a Wi-Fi module, a sensor, etc.

[0107] Understandably, Figure 4 The layers in the software structure shown and the components included in each layer do not constitute a specific limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 may include more or fewer layers than shown, and each layer may include more or fewer components, which is not limited in the present application.

[0108] It is understandable that, in order to implement the task submission method in the embodiment of the present application, the electronic device includes hardware and / or software modules corresponding to the execution of each function. In combination with the algorithm steps of each example described in the embodiment disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application in combination with the embodiments, but such implementation should not be considered to be beyond the scope of the present application.

[0109] In the task submission method provided in this embodiment, a kernel thread initialization phase and a task submission phase can be divided, wherein the processing flow of the kernel thread initialization phase can be implemented during the power-on phase of the electronic device.

[0110] In the kernel thread initialization phase, a worker thread is initialized on each CPU core, and a corresponding priority is set for each worker thread according to the CPU core where the worker thread is located.

[0111] like Figure 5The following is a schematic diagram of the interaction between the modules. Figure 5 In the kernel thread (or worker thread) initialization phase, the process of the task submission method provided in the embodiment of the present application specifically includes:

[0112] S201, the initialization subsystem creates multiple working threads and binds each working thread to a different CPU core.

[0113] During the startup phase of the electronic device, the initialization subsystem creates multiple work threads and binds each work thread to a different CPU core to process asynchronous tasks that need to be submitted to the non-core-bound work queue in the native mechanism of the Linux kernel. For example, if the electronic device includes N CPU cores, the initialization subsystem can create N work threads and bind the work threads to the CPU cores one-to-one. Among them, the priorities of different work threads are not the same.

[0114] The initialization subsystem may create one or more real-time working threads (hereinafter referred to as real-time threads) and one or more common working threads (hereinafter referred to as common threads). The priority of real-time threads is higher than that of common threads.

[0115] In the Linux kernel, ordinary threads and real-time threads can be distinguished based on thread priority. Real-time threads have real-time priority, with a default value of 0 to 99. The higher the value, the higher the priority. Ordinary threads have nice values, which are mapped to the user layer in the range of -20 to +19. The higher the value, the lower the priority. The default initial value is 0.

[0116] In a specific implementation, the initialization subsystem may create a real-time thread and multiple common threads, and bind the real-time thread to one of the CPU cores, and bind the multiple common threads to other CPU cores respectively. The real-time priority of the real-time thread may be set to a default value, and the nice value of each common thread may also be set to a default initial value.

[0117] S202: The initialization subsystem applies for memory space for each working thread from the memory management subsystem.

[0118] The initialization subsystem can call the API (Application Programming Interface) of the memory management subsystem to apply for memory space for the working threads bound to each CPU core.

[0119] S203: The memory management system allocates memory space to each working thread.

[0120] The initialization subsystem applies for memory space from the memory management system for each worker thread bound to each CPU core, and the memory management system can allocate memory space to each worker thread based on an existing memory allocation scheme. The memory allocation scheme can refer to the existing technology and will not be described here.

[0121] S204, the initialization subsystem sends a CPU core information acquisition request to the CPU management module.

[0122] The CPU core information acquisition request is used to obtain CPU core information from the CPU management module, including but not limited to the number of CPU cores and the ID information of each CPU core. For example, the ID information of the CPU core includes but is not limited to a series of CPU-related information such as CPU type, model, manufacturer information, trademark information, serial number, cache, etc.

[0123] This embodiment does not limit the execution order of S203 and S204.

[0124] S205, the CPU management module traverses the CPU information and sends the ID information of each CPU core to the initialization subsystem.

[0125] The CPU management module traverses the recorded CPU information, obtains the ID information of each CPU core, and feeds back the ID information of each CPU core to the initialization subsystem.

[0126] S206, the initialization subsystem calls the scheduling module to set a priority for each working thread according to the ID information of the CPU core to which the working thread is bound.

[0127] After obtaining the ID information of each CPU core, the initialization subsystem can call the scheduling module to set the priority of each worker thread, and write the priority set for each worker thread into the corresponding worker thread attribute. Among them, the priorities of worker threads bound to different CPU cores are different.

[0128] Exemplarily, the initialization subsystem may call the scheduling module through an API of the scheduling module to set the priority of the working thread bound to each CPU core.

[0129] S207, the scheduling module sets a priority for each working thread according to the ID of each CPU core, and returns the setting result to the initialization subsystem.

[0130] The scheduling module can determine the type of each CPU core based on the ID of each CPU core, for example, whether each CPU core is a small CPU core, a medium CPU core, or a large CPU core. Then, according to the type of the CPU core, the priority of the working thread (real-time thread or ordinary thread) bound to each CPU core can be set.

[0131] For example, Figure 6 As shown, the initialization subsystem creates work thread 1 and binds work thread 1 to one of the small CPU cores. Work thread 1 is a real-time thread. The initialization subsystem creates work thread 2, work thread 3, and work thread 4, and binds work thread 2 to another small CPU core, work thread 3 to the medium CPU core, and work thread 4 to the large CPU core. Work thread 2, work thread 3, and work thread 4 are ordinary threads. The scheduling module sets the priority of each work thread according to the type of the CPU core where the work thread is located.

[0132] Among them, the real-time thread has the highest priority, that is, the working thread 1 bound to one of the CPU cores has the highest priority. Among multiple ordinary threads, the higher the frequency of the CPU core to which the ordinary thread is bound, the lower the priority of the ordinary thread.

[0133] For example, refer to Figure 6 As shown in the figure, since the frequencies of the CPU small core, the CPU medium core, and the CPU large core increase in sequence, the priorities of the work thread 2, work thread 3, and work thread 4 respectively bound to the CPU small core, the CPU medium core, and the CPU large core decrease in sequence. That is, the priority of work thread 2 is higher than the priority of work thread 3, and the priority of work thread 3 is higher than the priority of work thread 4. Since the priority of the real-time thread is higher than the priority of all ordinary threads, the priority of work thread 1 is higher than the priority of work thread 2.

[0134] Among the multiple CPU cores of the electronic device, the number of CPU large cores may be one or more, the number of CPU medium cores may be one or more, and the number of CPU small cores may be multiple.

[0135] Optionally, in each CPU core of the electronic device, except for the CPU small core bound to the real-time thread, the priority of the working threads (all ordinary threads) bound to each CPU small core is the same, and the priority of the working threads (all ordinary threads) bound to each CPU core is also the same.

[0136] Take an 8-core CPU as an example. Each CPU core includes one large CPU core, three medium CPU cores, and four small CPU cores. Assume that a real-time thread n1 is created and bound to one of the small CPU cores; ordinary threads n2, n3, and n4 are created and bound to the remaining three small CPU cores respectively; ordinary threads n5, n6, and n7 are created and bound to the three medium CPU cores respectively; ordinary thread n8 is created and bound to the large CPU core. In this case, ordinary threads n2, n3, and n4 have the same priority, and ordinary threads n5, n6, and n7 have the same priority. Moreover, the priority of real-time thread n1 is higher than that of ordinary threads n2, n3, and n4, the priority of ordinary threads n2, n3, and n4 is higher than that of ordinary threads n5, n6, and n7, and the priority of ordinary threads n5, n6, and n7 is higher than that of ordinary threads n8.

[0137] Optionally, except for the CPU small core bound to the real-time thread, the priorities of the working threads (all ordinary threads) respectively bound to the other multiple CPU small cores may be the same or different, but the priorities of these working threads are higher than the priorities of the ordinary threads bound to the CPU medium core and the CPU large core. Similarly, the priorities of the multiple working threads (all ordinary threads) respectively bound to the CPU medium core may be the same or different, but the priorities of these working threads are higher than the priorities of the ordinary threads bound to the CPU large core.

[0138] Continuing with the previous example, the priorities of ordinary thread n2, ordinary thread n3, and ordinary thread n4 are not the same, and may be partially the same or completely different. For example, the priority of ordinary thread n2 is higher than the priority of ordinary thread n3, and the priority of ordinary thread n3 is higher than the priority of ordinary thread n4, and the priority of ordinary thread n4 is higher than the priority of ordinary thread n5, ordinary thread n6, ordinary thread n7, and ordinary thread n8. Similarly, the priorities of ordinary thread n5, ordinary thread n6, and ordinary thread n7 are not the same, and may be partially the same or completely different. For example, the priority of ordinary thread n5 is higher than the priority of ordinary thread n6, and the priority of ordinary thread n6 is higher than the priority of ordinary thread n7, and the priority of ordinary thread n7 is higher than the priority of ordinary thread n8.

[0139] In this embodiment, the scheduling module can set the priority of the real-time thread running on the CPU small core by adjusting the real-time priority, and can set the priority of each ordinary thread running on the CPU small core, CPU medium core and CPU large core by adjusting the nice value of the ordinary thread.

[0140] As an optional implementation, the setting result returned by the scheduling module to the initialization subsystem is used to indicate whether the setting is completed. Exemplarily, the scheduling module determines the priority information of each working thread according to the ID of each CPU core, and writes the priority information of each working thread into the corresponding working thread attribute (such as the working thread priority attribute). After the scheduling module completes setting the priority of each working thread, the scheduling module returns the setting result indicating that the setting is completed to the initialization subsystem.

[0141] As an optional implementation, the setting result returned by the scheduling module to the initialization subsystem includes the priority information of each working thread. Exemplarily, the scheduling module determines the priority information of each working thread according to the ID of each CPU core, and sends the priority information of each working thread to the initialization subsystem. Among them, the priority information of each working thread can be written into the corresponding working thread attribute by the scheduling module, and can also be written into the corresponding working thread attribute by the initialization subsystem, which is not limited in this embodiment.

[0142] S208, the initialization subsystem calls the RCU module to allocate an RCU protection pointer to each working thread.

[0143] Exemplarily, the initialization subsystem may call the RCU module through the API of the RCU module to allocate an RCU protection pointer to each working thread.

[0144] The RCU mechanism is a synchronization mechanism for shared data in the Linux kernel that is implemented for "read more, write less" scenarios. For shared data structures protected by RCU, readers can directly access them without acquiring any locks, but writers must first make a copy when accessing it, then modify the copy, and finally use a callback mechanism to redirect the pointer to the data to the new modified data at the appropriate time.

[0145] In this embodiment, since asynchronous tasks need to be submitted to working threads on different CPU cores for processing, concurrent protection of the thread pointers of each working thread can be implemented based on the RCU mechanism, thereby solving the concurrency security problem of multi-user processes submitting asynchronous tasks.

[0146] It is understandable that when each working thread is created, a corresponding thread pointer is generated, and the thread pointer is used to point to the working thread, or is referred to as the memory address pointing to the working thread. In this embodiment, the RCU protection pointer refers to a thread pointer protected by the RCU mechanism. Among them, the thread pointer can also be updated more safely based on the RCU protection mechanism.

[0147] S209, the RCU module allocates an RCU protection pointer to each working thread, and returns the allocation result to the initialization subsystem.

[0148] The allocation result may be used to indicate whether the allocation of the RCU protection pointer is completed for the working thread.

[0149] During the initialization phase of the working thread, the RCU module allocates an RCU protection pointer to the working thread (including real-time threads and ordinary threads) on each CPU core, and returns an allocation result indicating that the allocation has been completed to the initialization subsystem.

[0150] During the initialization phase, the initialization subsystem can call the rcu_assign_pointer method provided by the RCU module to assign a pointer value protected by the RCU mechanism to the thread pointer pointing to the working thread on each CPU core.

[0151] Among them, the thread pointer can be safely updated through rcu_assign_pointer. The implementation of rcu_assign_pointer will use the read barrier (Read Memory Barrier) provided by the RCU mechanism to ensure that other threads will not read the thread pointer value before the thread pointer is updated. In this way, the reading thread can ensure the consistency of the read operation through the RCU mechanism. In this embodiment, the reading thread can ensure the consistency of the read thread pointer operation through the RCU mechanism.

[0152] In the task submission phase, when a user-mode process generates an asynchronous task, the kernel function module corresponding to the asynchronous task (e.g., the file system module) can read the thread pointer of the kernel thread based on the RCU mechanism, and submit the corresponding asynchronous task to the kernel thread for execution based on the thread pointer. Among them, the kernel function module can be understood as a function module in the kernel layer for submitting asynchronous tasks to the kernel thread, which is not limited in this embodiment. The following takes the asynchronous task as an asynchronous task corresponding to the file system (such as a data reading task or a data updating task) and the kernel function module as a file system module as an example to explain the asynchronous task submission process.

[0153] In an optional implementation, the file system module may choose to submit the asynchronous task to a working thread on a CPU core for execution according to the control group (cgroup) to which the process to which the asynchronous task belongs belongs.

[0154] Since the scheduling priority of the processes in the foreground process group (or foregroup, abbreviated as fg) and the processes in the non-foreground process group (or background process group, or backgroup, abbreviated as bg) is the same, the foreground process is not scheduled preferentially on the CPU, which may cause the foreground process to freeze and affect the user experience.

[0155] In order to solve the above problem, the file system module can choose to submit the asynchronous task to the real-time thread on the CPU small core, or choose to submit the asynchronous task to an ordinary thread on the CPU small core, the CPU medium core, or the CPU large core, according to whether the cgroup to which the process to which the asynchronous task belongs is the foreground process group.

[0156] like Figure 7 As shown, after receiving the asynchronous task submitted by the user-state process, the file system module determines whether the cgroup where the user-state process is located is a foreground process group. If so, the asynchronous task is submitted to the real-time thread (i.e., working thread 1) running on the CPU small core for execution. If not, the asynchronous task can be submitted to the ordinary thread running on the CPU small core, the CPU medium core, or the CPU large core for execution according to the preset scheduling strategy.

[0157] In this embodiment, the cgroup module can determine whether the cgroup where the user state process is located is a foreground process group based on the foreground and background mechanism of cgroup. Among them, the main idea of ​​the foreground and background mechanism based on cgroup is to divide the processes of foreground applications into the foreground process group as much as possible, and divide the processes of background applications into the background process group as much as possible.

[0158] like Figure 8a The following is a schematic diagram of the interaction between the modules. Figure 8a In the asynchronous task submission stage, the process of the task submission method provided by the embodiment of the present application specifically includes:

[0159] S301: A first user-mode process submits an asynchronous task to a file system module.

[0160] The first user state process may be any foreground process, such as a process of any foreground application.

[0161] Exemplarily, when the WeChat application is running in the foreground of the mobile phone, the process of the WeChat application is the foreground process; exemplary, when the WeChat application and the video application are running in the foreground of the mobile phone at the same time, the process of the WeChat application and the process of the video application are both foreground processes.

[0162] Exemplarily, the asynchronous task submitted by the first user mode process to the file system module may be a task of reading data in the file system, a task of updating data in the file system, and the like.

[0163] The asynchronous task submitted by the first user state process to the file system module may be a task that needs to be submitted to a work queue that is not bound to a core in the native mechanism of the Linux kernel. In this embodiment, such asynchronous tasks that may need to be submitted to a work queue that is not bound to a core are no longer submitted to the work queue that is not bound to a core, but are directly submitted to the kernel thread.

[0164] S302: The file system module calls the cgroup module to determine the control group to which the process to which the asynchronous task belongs belongs.

[0165] Exemplarily, the file system module calls the API of the cgroup module to determine the control group to which the process to which the asynchronous task belongs (that is, the first user-mode process) belongs.

[0166] S303, the cgroup module determines whether the control group where the first user state process is located is a foreground process group. If so, the cgroup module returns the determination result that the control group where the first user state process is located is a foreground process group to the file system module.

[0167] The cgroup module determines whether the control group where the first user state process is located is a foreground process group based on the foreground and background mechanism of cgroup. In this embodiment, since the first user state process is a foreground process, the cgroup module returns the judgment result that the control group where the first user state process is located is a foreground process group to the file system module.

[0168] S304: The file system module determines, based on the determination result of the cgroup module, that the asynchronous task needs to be delivered to the real-time thread bound to the CPU core.

[0169] After determining that the control group where the first user-mode process is located is the foreground process group, the scheduling module determines that the asynchronous task needs to be submitted to the real-time thread on the CPU core to achieve the effect of timely responding to the asynchronous tasks generated by the foreground process and avoiding the problem of foreground process lag.

[0170] S305: The file system module calls the RCU module to obtain the RCU protection pointer value of the real-time thread.

[0171] S306: The RCU module obtains the RCU protection pointer value of the real-time thread based on the RCU mechanism, and returns the RCU protection pointer value of the real-time thread to the file system module.

[0172] The RCU protection pointer value of the real-time thread is the address value pointing to the real-time thread.

[0173] Under the call of the file system module, the RCU module obtains the RCU protection pointer value of the real-time thread based on the RCU mechanism, and returns the RCU protection pointer value of the real-time thread to the file system module.

[0174] When the file system module needs to read the RCU protection pointer of the real-time thread, it first calls the rcu_read_lock method provided by the RCU module to obtain the RCU read lock. In the RCU mechanism, read operations can be performed without locking or synchronization, but the RCU read lock is required to ensure that no concurrent data update operations occur during the reading process. After reading the lock, the file system module obtains the protected RCU pointer by calling the rcu_dereference method provided by the RCU module, that is, by calling the rcu_dereference method provided by the RCU module to obtain the RCU protection pointer of the real-time thread, which returns an address value pointing to the real-time thread that can be safely dereferenced. Finally, the file system module calls the rcu_read_unlock method provided by the RCU module to release the read lock.

[0175] The RCU mechanism allows reading data while updating it, improving the scalability of the synchronization mechanism. Compared with the traditional simple mutual exclusion lock mechanism that does not distinguish between readers and writers between concurrent threads, or the read-write lock that allows concurrent reading but not writing at the same time, the RCU mechanism supports the concurrency of one update thread (for example, a working thread that performs a thread address update task) and multiple reading threads (working threads that perform a thread address reading task). The RCU mechanism ensures the continuity of the read operation by saving multiple copies of the object, and ensures that the object will not be released before the predetermined read critical section is completed. In some cases (non-preemptive kernels), the data reading thread based on the RCU mechanism (i.e., the working thread that performs the thread address reading task) does not have any performance burden. For the parts that are not fully explained here, please refer to the existing technology and will not be repeated here.

[0176] S307, the file system module submits the asynchronous task to the real-time thread according to the RCU protection pointer value of the real-time thread.

[0177] S308, the real-time thread executes the asynchronous task and returns the task execution result to the first user state.

[0178] After obtaining the address value pointing to the real-time thread, the file system can submit the asynchronous task to the real-time thread. Then, when the real-time thread obtains the running right of the corresponding CPU core, it can execute the asynchronous task and return the task execution result to the first user state process after completing the asynchronous task.

[0179] It should be noted that before executing the asynchronous task, the real-time thread may have other tasks to process, and the real-time thread can determine the order of task execution based on the corresponding task scheduling strategy, which is not limited in this embodiment. Among them, when the task to be executed by the real-time thread is the asynchronous task submitted by the first user state process mentioned above, and the real-time thread obtains the running right of the CPU core bound to it, the asynchronous task submitted by the first user state process mentioned above can be executed by this real-time thread.

[0180] In this embodiment, for asynchronous tasks generated by foreground processes that may need to be submitted to the non-core-bound work queue, they are no longer submitted to the non-core-bound work queue, but are directly submitted to the real-time thread bound to the CPU small core for execution. Since the CPU small core is relatively idle, the real-time thread can also obtain the running right of the CPU small core more quickly, so that the asynchronous task can be executed earlier, avoiding the problem of high task scheduling delay, and thus solving the problem of foreground process jamming, improving the user experience.

[0181] like Figure 8b The following is a schematic diagram of the interaction between the modules. Figure 8b In the asynchronous task submission stage, the process of the task submission method provided by the embodiment of the present application specifically includes:

[0182] S401: The second user state process submits an asynchronous task to the file system module.

[0183] The second user state process may be any non-foreground process (or background process), such as any background application process.

[0184] Exemplarily, when a user-level application or a system-level application runs in the background of a mobile phone, the process of the user-level application or the system-level application is a background process.

[0185] Exemplarily, the asynchronous task submitted by the second user mode process to the file system module may be a task of reading data in the file system, a task of updating data in the file system, and the like.

[0186] The asynchronous task submitted by the second user state process to the file system module may be a task that needs to be submitted to a work queue that is not bound to a core in the native mechanism of the Linux kernel. In this embodiment, such asynchronous tasks that may need to be submitted to a work queue that is not bound to a core are no longer submitted to the work queue that is not bound to a core, but are directly submitted to the kernel thread.

[0187] S402: The file system module calls the cgroup module to determine the control group to which the process to which the asynchronous task belongs belongs.

[0188] Exemplarily, the file system module calls the API of the cgroup module to determine the control group to which the process to which the asynchronous task belongs (that is, the second user-mode process) belongs.

[0189] S403, the cgroup module determines whether the control group where the second user state process is located is a foreground process group. If not, the cgroup module returns the determination result that the control group where the second user state process is located is a non-foreground process group to the file system module.

[0190] The cgroup module determines whether the control group where the second user state process is located is a foreground process group based on the foreground and background mechanism of cgroup. In this embodiment, since the second user state process is a non-foreground process, the cgroup module can return the judgment result that the control group where the second user state process is located is a non-foreground process group to the file system module.

[0191] S404: The file system module determines, based on the determination result of the cgroup module, that the asynchronous task needs to be delivered to a common thread bound to a small CPU core, a medium CPU core, or a large CPU core.

[0192] After determining that the control group where the second user-mode process is located is a non-foreground process group, the file system determines that the asynchronous task needs to be submitted to an ordinary thread bound to the CPU small core, the CPU medium core, or the CPU large core, so as to solve the problem that the CPU core on which the work thread runs cannot be selected when submitting tasks based on an unbound core work queue.

[0193] Exemplarily, since the priorities of ordinary threads on the CPU small core, CPU medium core, and CPU large core are different, the file system module can select an ordinary thread with the highest priority to execute the asynchronous task submitted by the second user mode process.

[0194] As another example, since the priorities of ordinary threads on the CPU small core, CPU medium core, and CPU large core are different, the file system module can select an idle and higher-priority ordinary thread to execute the asynchronous task submitted by the second user mode process.

[0195] As another example, since the priorities of ordinary threads on the CPU small core, CPU medium core, and CPU large core are different, the file system module can sort the ordinary threads on the CPU small core, CPU medium core, and CPU large core according to their priorities, and after receiving an asynchronous task generated by a non-background process, select one of these ordinary threads in turn to execute the asynchronous task submitted by the user-state process, so that these ordinary threads on the CPU small core, CPU medium core, and CPU large core can evenly share the asynchronous tasks submitted by each user-state process, and try to achieve a load balancing effect.

[0196] As an optional real-time method, the file system module determines that the asynchronous task needs to be submitted to a common thread according to the judgment result of the cgroup module, and calls the scheduling module to select a common thread from multiple common threads bound to the small core of the CPU, the middle core of the CPU, and the large core of the CPU, so as to execute the asynchronous task submitted by the second user state process through this common thread. Among them, the scheduling module can select a common thread from multiple common threads bound to the small core of the CPU, the middle core of the CPU, and the large core of the CPU based on a preset scheduling policy. For example, the scheduling module can select a common thread based on the priority of the common thread and the idleness of each CPU core to execute the asynchronous task submitted by the second user state process.

[0197] S405: The file system module calls the RCU module to obtain the RCU protection pointer value of the common thread.

[0198] S406: The RCU module obtains the RCU protection pointer value of the common thread based on the RCU mechanism, and returns the RCU protection pointer value of the common thread to the file system module.

[0199] Among them, the RCU protection pointer value of the ordinary thread is the address value pointing to the ordinary thread.

[0200] Under the call of the file system module, the RCU module obtains the RCU protection pointer value of this ordinary thread based on the RCU mechanism, and returns the RCU protection pointer value of this ordinary thread to the file system module.

[0201] When the file system module needs to read the RCU protection pointer of a normal thread, it first calls the rcu_read_lock method provided by the RCU module to obtain the RCU read lock. After reading the lock, the file system module obtains the protected RCU pointer by calling the rcu_dereference method provided by the RCU module, that is, by calling the rcu_dereference method provided by the RCU module to obtain the RCU protection pointer of the normal thread, which returns an address value pointing to the normal thread that can be safely dereferenced. Finally, the file system module calls the rcu_read_unlock method provided by the RCU module to release the read lock.

[0202] S407, the file system module submits the asynchronous task to the corresponding common thread according to the RCU protection pointer value of the common thread.

[0203] S408, the common thread executes the asynchronous task and returns the task execution result to the second user state.

[0204] After obtaining the address value pointing to the ordinary thread, the file system can submit the asynchronous task to the corresponding ordinary thread. Then, when the ordinary thread obtains the running right of the CPU core bound to it, it executes the asynchronous task and returns the task execution result to the second user state process after completing the asynchronous task.

[0205] It should be noted that before executing the asynchronous task, the ordinary thread may have other tasks to process, and the ordinary thread can determine the order of task execution based on the corresponding task scheduling policy, which is not limited in this embodiment. Among them, when the task that the ordinary thread is about to execute is the asynchronous task submitted by the second user state process mentioned above, and the ordinary thread obtains the running right of the CPU core bound to it, the asynchronous task submitted by the second user state process mentioned above can be executed by the ordinary thread.

[0206] In this embodiment, for asynchronous tasks generated by non-foreground processes that may need to be submitted to the unbound core work queue, they are no longer submitted to the unbound core work queue, but are directly submitted to ordinary threads bound to the CPU small core, CPU medium core, or CPU large core for execution. This solves the problem that when submitting tasks based on the unbound core work queue, the CPU core on which the work thread runs cannot be selected, and reduces the delay in task scheduling.

[0207] In the task submission method provided in the embodiment of the present application, for asynchronous tasks that may need to be submitted to the non-core-bound work queue, they are no longer submitted to the non-core-bound work queue, but are directly submitted to the work thread bound to a certain CPU core for execution, thereby optimizing the asynchronous task submission method based on the non-core-bound work queue in the native mechanism of the Linux kernel. Among them, the priorities of work threads on different CPU cores are different. When submitting an asynchronous task, the work thread that executes the asynchronous task can be selected based on whether the control group to which the process to which the asynchronous task belongs is located is the foreground task group, and then the CPU core that executes the asynchronous task is determined, which not only solves the problem that the CPU core on which the work thread runs cannot be selected when submitting a task based on the non-core-bound work queue, but also can achieve the effect of prioritizing the scheduling of asynchronous tasks generated by the foreground process, avoiding the phenomenon of foreground application freezes.

[0208] This embodiment also provides a computer storage medium, in which computer instructions are stored. When the computer instructions are executed on an electronic device, the electronic device executes the above-mentioned related method steps to implement the task submission method in the above-mentioned embodiment.

[0209] This embodiment also provides a computer program product. When the computer program product runs on a computer, it enables the computer to execute the above-mentioned related steps to implement the task submission method in the above-mentioned embodiment.

[0210] In addition, an embodiment of the present application also provides a device, which can specifically be a chip, component or module, and the device may include a connected processor and memory; wherein the memory is used to store computer execution instructions, and when the device is running, the processor can execute the computer execution instructions stored in the memory so that the chip executes the task submission method in the above-mentioned method embodiments.

[0211] Among them, the electronic device (such as a mobile phone, etc.), computer storage medium, computer program product or chip provided in this embodiment is used to execute the corresponding method provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding method provided above, and will not be repeated here.

[0212] Through the description of the above implementation methods, technical personnel in the relevant field can understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0213] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic, for example, the division of modules or units is only a logical function division, and there may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0214] As described above, the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A task submission method, characterized in that: Used in electronic equipment, including: During the startup phase of the electronic device, a real-time working thread and at least one common working thread are created, and the real-time working thread is bound to the first CPU core, and the at least one common working thread is respectively bound to other CPU cores included in the electronic device; wherein, among the multiple CPU cores included in the electronic device, the frequency of the first CPU core is the lowest; Obtain a target asynchronous task generated by a target user state process; the target asynchronous task is a task that needs to be submitted to a work queue in a native mechanism of the Linux kernel, and the work queue is not bound to a CPU core; the target asynchronous task includes a data reading task or a data updating task for a file system; When the target user state process belongs to the foreground process group, submitting the target asynchronous task to the real-time working thread, and the real-time working thread executes the target asynchronous task; When the target user state process belongs to a non-foreground process group, the target asynchronous task is submitted to one of the common working threads, and one of the common working threads executes the target asynchronous task.

2. The method according to claim 1, characterized in that The plurality of CPU cores further include at least one second CPU core, at least one third CPU core, and at least one fourth CPU core; The frequency of the second CPU core is the same as that of the first CPU core, the frequency of the second CPU core is lower than the frequency of the third CPU core, and the frequency of the third CPU core is lower than the frequency of the fourth CPU core.

3. The method according to claim 2, characterized in that Binding the at least one common working thread to other CPU cores included in the electronic device respectively includes: The at least one common working thread is bound to the second CPU core, the third CPU core, and the fourth CPU core respectively.

4. The method according to claim 3, characterized in that Also includes: According to the type of CPU core to which the common working thread is bound, setting the priority of each of the common working threads; Among them, the priority of the ordinary working thread bound to the second CPU core is higher than the priority of the ordinary working thread bound to the third CPU core, and the priority of the ordinary working thread bound to the third CPU core is higher than the priority of the ordinary working thread bound to the fourth CPU core.

5. The method according to claim 4, characterized in that Submitting the target asynchronous task to one of the common working threads includes: According to the priority of each of the ordinary working threads, one ordinary working thread is selected from the plurality of ordinary working threads, and the target asynchronous task is submitted to the one ordinary working thread.

6. The method according to any one of claims 1 to 5, characterized in that: After creating a target work thread, the target work thread includes a real-time work thread or a common work thread, and further includes: A thread pointer is allocated to the target working thread; wherein the thread pointer is a pointer protected based on an RCU mechanism, and the value of the thread pointer is used to point to the address of the target working thread.

7. The method according to claim 6, characterized in that Submitting the target asynchronous task to the target working thread includes: Obtaining the thread pointer value of the target working thread based on the RCU mechanism; According to the thread pointer value of the target working thread, the target asynchronous task is submitted to the target working thread.

8. An electronic device, characterized in that: include: one or more processors; Memory; and one or more computer programs, wherein the one or more computer programs are stored in the memory, and when the computer programs are executed by the one or more processors, the electronic device executes the task submission method as described in any one of claims 1-7.

9. A computer-readable storage medium comprising a computer program, characterized in that: When the computer program is executed on an electronic device, the electronic device is enabled to execute the task submission method according to any one of claims 1 to 7.

Images