Input / output request processing method and related equipment

Abstract

The invention provides an input / output request processing method and related equipment, which can be applied to electronic equipment such as a mobile phone. In the method, one or more preset groups can be defined in advance, and when the input and output requests are processed, the input and output requests of the threads in the preset groups can be added into a high-priority software queue to be processed, so that the input and output requests of the threads are processed preferentially, the processing time is shortened, and the processing efficiency is improved. And the problem that the user experience is reduced due to delayed processing of the threads is relieved.

Description

Technical Field

[0001] This application belongs to the field of electronic devices, and particularly relates to a method for processing input / output requests and related devices. Background Art

[0002] With the intelligent development of electronic devices, users can install various applications in electronic devices to meet the needs of daily life and work, such as video applications, game applications, and instant messaging applications, etc.

[0003] However, as applications are designed to be more and more complex, and the number of applications installed on electronic devices is increasing, when users use applications on electronic devices, there are often situations where the application loading is slow, or the application lags when interacting with the application, which greatly affects the user experience. Summary of the Invention

[0004] Embodiments of this application provide a method for processing input / output requests and related devices, which can improve the processing priority of input / output requests of threads within a preset group, and alleviate the problem of the decline in user experience caused by the delayed processing of these threads.

[0005] In a first aspect, a method for processing input / output (IO) requests is provided. This method can be applied to an electronic device. Specifically, the method includes: after receiving a first IO request of a first thread, determining whether the first thread is a thread within a preset group; if so, adding the first IO request to a first software queue in a software queue set for scheduling processing. Among them, the software queue set further includes a second software queue, and the scheduling priority of the first software queue is higher than that of the second software queue.

[0006] In an example, the first software queue is the software queue with the highest scheduling priority among multiple software queues in the software queue set. It can be understood that the electronic device will preferentially schedule IO requests in software queues with a high scheduling priority.

[0007] Through the above solution, the problem of interface lag in some user scenarios, especially some heavy-load scenarios, can be alleviated. For example, when an electronic device performs mirror merging (merge) and memory page swapping (swapin) after being upgraded through over-the-air technology (OTA), or during the application startup process, a large number of IO requests will be concurrent, and the background / sudden load will become high, which may exceed the processing capacity of the device, resulting in a large number of IO requests being blocked. Some IO requests that are sensitive to latency cannot be processed in a timely manner, which may cause the interface to lag. In the solution provided in this application, a preset group is predefined, and the IO requests of the critical threads within the preset group are preferentially scheduled and processed on the software side, thereby alleviating the problem of interface lag caused by IO blocking when implementing user interaction on the user interface.

[0008] Optionally, the above preset group can be created based on a preset rule. The threads within the preset group are threads related to the lag problem that occurs in user interaction events. As an example, the threads within the preset group are the threads that execute the relevant tasks in user interaction events. Whether these threads can run smoothly determines whether a user-perceivable lag will occur in the user interface of the process. Therefore, preferentially scheduling and processing the IO requests of these threads can alleviate the lag situation that occurs when executing user interaction events due to IO request blocking.

[0009] Optionally, the preset group includes at least one of the following threads: user interface (UI) thread, Render thread, graphics library (GL) thread, distribution thread of user input events, detection thread of user input events.

[0010] Optionally, determining whether the first thread is a thread within the preset group includes: determining whether the first thread is a thread within the preset group according to the pre-configured information and the grouping information of the first thread.

[0011] Based on the above solution, the identification information of the preset group is pre-configured for the electronic device. When the identification information of the group carried in the received first IO request matches the identification information of the preset group, it indicates that the first thread belongs to the preset group. By pre-configuring the grouping information in this way, the latency caused by grouping judgment can be reduced, and the processing efficiency of IO requests can be improved.

[0012] Optionally, determining whether the first thread is a thread within the preset group includes: determining whether the first thread is a thread within the preset group according to the attribute information of the first thread.

[0013] Based on the above solution, after receiving the first IO request, it is possible to temporarily determine whether the first thread belongs to a preset group according to the attribute information of the first thread. Specifically, the criteria for judgment can be pre-configured, and then the judgment can be made based on this criteria. For example, when the first thread is a UI thread, a Render thread, a GL thread, or a thread that has a dependency relationship with a UI thread, a Render thread, or a GL thread, it is determined that the first thread belongs to the preset group. In this way, it is not necessary to pre-configure the group, which reduces the complexity of the IO processing flow, and the judgment rules can be adjusted more flexibly. For example, after the dependency relationship between a certain thread and the UI thread is removed, the thread can be automatically removed from the preset group.

[0014] Optionally, before adding the IO request to the first queue in the queue set for scheduling and processing, the method further includes: determining that the IO type of the IO request is a read operation.

[0015] Since the IO request with the IO type of read operation is related to the data reading operation, which is usually manifested in scenarios such as application startup and application data loading, it usually belongs to the related tasks in the user interaction event, that is, it is closely related to the user experience. Therefore, preferentially processing this part of the IO requests is beneficial to reducing the situation of the interaction interface jamming when the user uses the electronic device and improving the user experience.

[0016] Optionally, the method further includes: adding a first tag to the control command; sending the control command to the hardware layer, where the control command is used to instruct the memory in the hardware layer to process the IO request, and the first tag is used to instruct the memory to process the first IO request according to the highest priority supported by the hardware queue after adding the first IO request to the hardware queue.

[0017] In the above solution, a first tag can be added to the control command sent to the hardware layer to instruct the memory in the hardware layer to preferentially process the first IO request of the first thread belonging to the preset group, thereby improving the hardware processing efficiency of the first IO request.

[0018] Optionally, adding a first tag to the control command includes: judging whether the first thread is a real-time thread; in the case where the first thread is a real-time thread, adding a first tag to the control command.

[0019] Based on the above solution, the first label can be added only to the real-time threads in the preset group, that is, only the hardware processing priority of the real-time threads in the preset group is improved. For example, if the first thread is a real-time thread, it means that the original software scheduling priority of the first IO request is the high priority. Therefore, the hardware processing priority of the first IO request can be further improved on this basis to distinguish the priority order of the IO requests corresponding to different threads in the preset group. That is to say, for the non-real-time threads in the preset group, only the software scheduling priority is improved, and the hardware processing priority is not improved; for the real-time threads in the preset group, both the software scheduling priority and the hardware processing priority are improved.

[0020] Optionally, adding the first label in the control command includes: obtaining the first blocking input / output (BIO) from the file system through the recognition module, and adding a second label to the first BIO to obtain the second BIO, where the first BIO is a file of the BIO structure based on the IO request; obtaining the second BIO from the recognition module through the IO scheduler, and adding a third label to the request message based on the second label, where the request message is a message of the request structure based on the second BIO; obtaining the request message from the IO scheduler through the hardware driver, and adding the first label to the control command based on the third label.

[0021] Through the above method, the first label used to indicate improving the hardware processing priority of the first IO request can be transmitted from the recognition module to the memory in the hardware layer, so that the memory can give priority to processing the first IO request.

[0022] Optionally, after scheduling and processing the first IO request by adding it to the first software queue in the software queue set, the method further includes: when the first software queue is empty, obtaining a first quantity, where the first quantity is the quantity of the second IO requests that have been scheduled and dispatched but not processed completely, and the second IO requests correspond to a second thread that does not belong to the preset group; and dispatching the second IO requests in the case that the first quantity is less than or equal to a first threshold.

[0023] In this way, it is not necessary to wait for all the IO requests in the first software queue to be processed completely before dispatching the IO requests in the second software queue, thereby reducing the waiting time of the second IO requests and improving the dispatching efficiency of the IO requests. On the other hand, the quantity of the second IO requests that have been dispatched but not processed (i.e., the quantity of the second IO requests not processed in the hardware queue) can also be controlled, thereby reducing the situation where task blocking may be caused by excessive bandwidth pressure.

[0024] Optionally, when the first quantity is greater than the first threshold, the method further includes: determining whether all the input / output requests dispatched from the first software queue have been processed; when all the input / output requests dispatched from the first software queue have been processed, dispatching a second input / output request; or, stopping the dispatching of the second IO request.

[0025] Exemplarily, if the first quantity is greater than the first threshold, the dispatching of the second IO request can be stopped to prevent the situation where the second IO request affects the priority processing of the first IO request; or, if the first quantity is greater than the first threshold, it can also be continued to determine whether all the IO requests in the first software queue have been processed. If all have been processed (that is, all the IO requests in the first software queue have been dispatched and all have been processed), at this time, there is no need to worry about the problem that the processing delay becomes large due to too many second IO requests to be processed in the hardware queue for some IO requests in the first software queue. Therefore, the IO requests in the second software queue can be directly dispatched.

[0026] In a second aspect, an electronic device is provided, including a memory and a processor. A computer program that can run on the processor is stored on the memory. When the processor executes the computer program, the electronic device implements the steps of the method for processing captured data as described in any one of the above first aspects.

[0027] In a third aspect, a computer-readable storage medium is provided. The computer-readable storage medium stores a computer program. When the computer program is executed by a processor, the steps of the method for processing captured data as described in any one of the above first aspects are implemented.

[0028] In a fourth aspect, a computer program product is provided. When the computer program product runs on an electronic device, the electronic device is caused to execute the method for processing captured data as described in any one of the above first aspects.

[0029] In a fifth aspect, a chip system is provided. The chip system includes a processor. The processor is coupled to a memory. The processor executes a computer program stored in the memory to implement the method for processing captured data as described in any one of the above first aspects.

[0030] Wherein, the chip system can be a single chip or a chip module composed of multiple chips.

[0031] It can be understood that the beneficial effects of the above second aspect to fifth aspect can refer to the relevant descriptions in the above first aspect, and will not be elaborated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1 An exemplary architecture diagram of a system architecture 100 applicable to embodiments of the present application is shown;

[0033] Figure 2 shows an exemplary flowchart of method 200 provided by an embodiment of the present application;

[0034] Figure 3 shows an exemplary flowchart of a method for adjusting the software and hardware priorities of IO requests provided by an embodiment of the present application;

[0035] Figure 4 shows an exemplary flowchart of a method for bandwidth control provided by an embodiment of the present application;

[0036] Figure 5 shows an exemplary system architecture diagram provided by an embodiment of the present application;

[0037] Figure 6 shows an exemplary block diagram of method 600 provided by an embodiment of the present application;

[0038] Figure 7 shows an exemplary structural diagram of electronic device 700 provided by an embodiment of the present application. Detailed implementation manners

[0039] Next, the technical solutions in the embodiments of the present application will be described with reference to the accompanying drawings in the embodiments of the present application. To describe the embodiments of the present application more clearly, some terms or technologies related to the embodiments of the present application will be briefly introduced first.

[0040] As mentioned in the background art section, users can install various applications on an electronic device to implement various functions. However, when using the electronic device, users find that sometimes it takes a relatively long time to open some applications, that is, the loading time of the application startup page is relatively long; sometimes when interacting with an application, such as clicking on a certain control within the user interface of an application or performing a sliding operation within the application, there will be a lag situation. These situations will all affect the user experience.

[0041] In view of this, the embodiments of the present application provide a method for processing IO requests, which can reduce the processing delay of IO requests of some key threads that may affect the user experience, thereby reducing the lag of the interaction interface and improving the user experience. Specifically, multiple groups can be established in advance, different threads can be divided into different groups according to certain rules, and at least one of the multiple groups is preset as a key group (hereinafter simply referred to as a preset group). When an IO request of a thread within the preset group is received, the IO request is preferentially scheduled to reduce the scheduling delay of the IO request, thereby reducing the duration of the IO request being blocked. The following combines Figures 1 to 6 to introduce in detail the system architecture and specific implementation process corresponding to this method.

[0042] The method for processing input / output requests provided by the embodiments of this application can be applied to electronic devices, such as mobile phones, tablet computers, desktop computers, laptop computers, handheld computers, notebook computers, ultra-mobile personal computers (UMPCs), netbooks, as well as cellular phones, personal digital assistants (PDAs), augmented reality (AR) devices, virtual reality (VR) devices, artificial intelligence (AI) devices, wearable devices, in-vehicle devices, smart home devices, and / or smart city devices, etc. The embodiments of this application do not impose special restrictions on the specific types of such electronic devices. The system architecture of the electronic device can adopt a layered architecture, an event-driven architecture, a microkernel architecture, a microservices architecture, or a cloud architecture, etc. The embodiments of this application take the Android system with a layered architecture as an example to exemplarily illustrate the system architecture of the electronic device.

[0043] The operating system of the electronic device in the embodiments of this application can be, for example, a system based on the linux kernel (such as the Android operating system), and the specific system architecture can be a layered architecture, as Figure 1 shown. The layered architecture divides the software system into several layers, and each layer has a clear role and division of labor. The layers communicate with each other through software interfaces. In Figure 1 the example shown, the software architecture part of the electronic device includes an Application layer and a Kernel layer, and the hardware architecture part includes a hardware layer. It can be understood that Figure 1 the system architecture shown is only an example, and in actual applications, there may also be other layers. For example, the software architecture part of the electronic device may also include an Application Framework layer, an Android runtime, and system libraries, a hardware abstraction layer (HAL), etc.

[0044] Among them, the Application layer can include various applications, such as games, cameras, address books, phones, messages, clocks, calendars, galleries, memos, music, weather, shopping malls, etc.

[0045] The system processes and application processes are running on the electronic device. A thread is an execution path of a process, the smallest unit during program execution, and also the basic unit for memory allocation. A process can have multiple threads, but at least one thread. The operation of the system processes and application processes on the electronic device requires the system kernel to allocate memory space for them. And as the system runs, the kernel continuously performs operations such as memory recycling and allocation.

[0046] For the kernel, when performing resource scheduling, such as central processing unit (CPU) scheduling, it is specific to a certain thread. There is a main thread in a process, and it will also create many child threads to assist in work. For example, in the process of a content interaction application, it will create a main thread to execute the code, and other child threads will also be created during the execution to assist in running the task code of each part.

[0047] In a computer system, during the program running process, a series of operations need to be performed on the executable program code segment and resource files. For example, reading data from a storage device into memory (such as what can be called a read operation), writing the data that needs to be persisted back to the storage device (such as what can be called a write operation), etc. These operations are implemented by different IO requests within the system. Specifically, the Linux system manages memory in pages, and different operations (such as the above-mentioned read operation or write operation) can be achieved by different threads sending different IO requests. As Figure 1 shown, the thread within the application can send a first IO request to the file system at the kernel layer to request data processing, such as reading data or writing data.

[0048] Among them, the kernel layer is the layer between hardware and software, and can include a file system (FS), a page cache (not shown in the figure), a general block layer, and a device driver.

[0049] Among them, the file system (FS) and the page cache are used to manage the cached file pages and temporarily store file data.

[0050] When the file system receives the first IO request triggered by a thread and starts an IO operation, it can submit a BIO structure to the block layer. For example, the file system layer can submit a BIO structure to the block layer by calling submit_bio. The BIO structure is the data structure of the IO request in the block layer. The BIO structure represents a running IO operation, that is, an IO request can be represented by a BIO structure. For convenience, the BIO structure submitted by the file system is denoted as BIO#1.

[0051] In the embodiment of the present application, an identification module is also set between the file system and the block. The identification module can be a newly added module in the kernel layer or a module reused after enhancing an existing functional module, which is not limited here. When the identification module is a newly added module, the identification module can be kernel object (KO) - enabled by registering a hook function of the block layer trace point in the identification module, that is, registering the identification module as a KO module. The KO module is a loadable module in the kernel. It can dynamically add functions to the kernel. At runtime, the kernel functions can be extended or reduced by dynamically loading or unloading the KO module without making invasive modifications to the kernel.

[0052] The identification module in the embodiment of the present application can obtain BIO#1 from the file system and determine whether the thread triggering the IO operation is a thread that needs to be preferentially processed according to the BIO#1, that is, determine whether the first IO request needs to be preferentially processed. For example, the identification module can determine whether the thread belongs to a thread within a preset group. If so, the thread can be set as a high - priority thread, such as setting the thread as a real - time RT thread. Optionally, a tag can also be added to BIO#1 to obtain BIO#2 to indicate that the IO operation corresponding to BIO#2 is preferentially processed. The specific process can refer to steps S203 - S207 in the subsequent method 200, which will not be elaborated here for the time being.

[0053] The block layer can provide multiple interfaces for processing IO requests. The block layer includes an IO scheduler (IOScheduler). The IO scheduler is used to manage the request queue of IO requests. It can determine the order of requests in the queue and the time when requests are dispatched. As an example, the IO scheduler described in the embodiment of the present application is a multi - queue deadline (MQ - Deadline) scheduler.

[0054] Dispatching IO requests in a certain order through an IO scheduler helps reduce disk addressing time and improve overall performance. It should be noted that the IO scheduler dispatching IO requests means that the IO scheduler performs scheduling and processing on the IO requests, specifically, triggering through the device driver to send the IO requests to the hardware queue managed by the memory.

[0055] The IO scheduler can place the IO requests corresponding to high-priority threads in the high-priority queue for scheduling and processing, and place the IO requests corresponding to low-priority threads in the low-priority queue for scheduling and processing.

[0056] Then, the IO scheduler also needs to convert the received BIO#2 into a message of the request structure (denoted as request), and send this request to the device driver. It can be understood that if BIO#2 carries a label for indicating priority processing, then this label is also carried in the request.

[0057] The device driver is the interface between the IO system and the relevant hardware, and is used to drive the corresponding hardware device. Device drivers include, for example, memory drivers, camera drivers, processor drivers, display drivers, audio drivers, etc. The device driver can convert the received request into an IO command (denoted as cmd), and through this cmd, instruct the devices in the hardware layer ( Figure 1 taking the memory as an example) to perform corresponding IO operations.

[0058] The memory in the hardware layer processes the corresponding data processing requests according to the received cmd according to the hardware processing priority. For details, reference can be made to the description of step S212 in method 200, and no detailed description will be given here for the time being.

[0059] The following combines Figure 2 in method 200 to make an exemplary description of the method flow executed by each module in the Figure 1 software architecture.

[0060] S201. The first thread in the application sends a first IO request to the file system.

[0061] Exemplarily, when the application is starting up or running, it needs to perform some operations on the data. At this time, it can be realized by triggering an IO request through the thread executing the corresponding function in the application. For example, the first thread in the application sends a first IO request to the file system to request data processing. Specifically, for example, in response to the operation of the user clicking the icon of the application, the electronic device starts the application, and the UI thread or Render thread of the application will trigger a first IO request to the kernel layer to request to read the corresponding data.

[0062] In one example, when the I / O type of the first I / O request is a read operation, it is possible to first check whether the data to be read is stored in the page cache. If it exists (i.e., cache hit), the data can be directly read from the page cache. Since the page cache is a cache, the data reading efficiency can be improved. If it does not exist, the first I / O request is sent to the file system so that the corresponding data can be read from the memory in the hardware layer through I / O operations subsequently.

[0063] S202. The file system sends BIO#1 to the recognition module.

[0064] Exemplarily, after the file system receives the first I / O request triggered by the first thread, it calls submit_bio to submit a BIO structure to the recognition module, denoted as BIO#1. This BIO#1 is used to trigger the block layer to schedule and process the I / O request of the first thread. The BIO#1 includes the attribute information of the first I / O request. For example, the I / O type of the first I / O request (including read operation, write operation, flush, passthrough, etc.), the group to which the first thread belongs, and the type of the first thread (including complete fair schedule (CFS) thread, real time (RT) thread, etc.).

[0065] It can be understood that the recognition module is located between the file system and the block layer. The file system submits BIO#1 to the recognition module, aiming to have the recognition module submit it to the block layer.

[0066] S203. The recognition module checks the I / O type.

[0067] Optionally, after the recognition module obtains BIO#1, it checks the I / O type of the first I / O request according to BIO#1. In a possible implementation, if the I / O type of the first I / O request is a read operation, the recognition module can continue to execute step S204. If the I / O type of the first I / O request is a non-read operation, such as write operation, flush, passthrough, the recognition module can skip steps S204 - S207 and directly execute step S208 (at this time, the BIO#2 sent in S208 is the same as BIO#1).

[0068] Since the IO requests with the read operation as the IO type are related to data reading operations, which are usually manifested in scenarios such as application startup and application data loading, they generally belong to the relevant tasks in user interaction events, that is, they are closely related to the user experience. Therefore, preferentially processing this part of the IO requests is beneficial to reducing the situation of the interaction interface jamming when the user uses the electronic device and improving the user experience.

[0069] S204. The recognition module checks the group to which the first thread belongs.

[0070] S205. If the first thread belongs to a preset group, increase the scheduling priority.

[0071] Exemplarily, after determining that the IO type of the first IO request is a read operation, the recognition module can further check the group (cgroup) to which the first thread belongs according to BIO#1.

[0072] That is to say, in the method provided by the embodiments of the present application, different threads can be pre-divided into different groups in advance, and each group can correspond to a unique identifier. When the first thread triggers the first IO request, the identifier of the group to which the first thread belongs can be carried in the first IO request, and this identifier will be inherited by BIO#1. The present application does not limit the way of grouping threads, nor the specific number of groups, and the threads in the thread application can be divided into a limited number of groups according to actual business needs.

[0073] In addition, at least one of the multiple groups can be set as a preset group in advance, and the identifier of the preset group can be pre-configured to the recognition module so that the recognition module can determine whether different threads belong to the preset group according to the identifier of the preset group. For example, a total of four groups are divided: Group 1, Group 2, Group 3, and Group 4, and each group corresponds to one or more threads. Developers can set one or more of them as preset groups according to actual business needs. For example, Group 1 is set as a preset group, and then the identifier of Group 1 is pre-configured to the recognition module.

[0074] In a possible implementation manner, the threads in the preset group are the threads that execute the relevant tasks in the user interaction event.

[0075] In one embodiment, the preset group includes some threads created during the process operation for directly executing the relevant tasks of the user interaction event, such as the UI thread, the Render thread, the GL thread, the distribution thread of the user input event, the detection thread of the user input event, etc. Whether these threads can run smoothly determines whether there will be a user-perceivable jam in the interaction interface between the user and the process.

[0076] Among them, the threads within the preset group are generally application-level threads, and it is possible to determine which threads belong to the preset group by analyzing the actual lag scenarios.

[0077] For example, if application lag occurs in a certain user interaction scenario, by testing this scenario and analyzing which thread is handling tasks too slowly to cause the lag phenomenon, the thread that can be used to execute relevant tasks in the user interaction event, and whose operation is closely related to the user experience, can be added to the preset group.

[0078] Since during the execution of user interaction events, in addition to application-level threads, some system-level threads may also be involved in completing tasks. At this time, these system-level threads also need to be marked as threads within the preset group. Generally, these threads are created when the system starts. Therefore, when detecting the system startup, these threads can be identified and marked. For example, the Surfaceflinger thread, the system animation thread, etc. Or, during the system operation, if it is detected that new threads of a system process are created and used to execute relevant tasks in the user interaction event, these threads can also be marked as threads within the preset group.

[0079] In one implementation, there are also some threads that do not directly execute relevant tasks of user interaction events, but the running conditions of these threads will also affect the running conditions of the threads within the preset group, and thus indirectly affect the execution of relevant tasks of user interaction events. That is to say, these threads are not always related to the user experience, but during a certain period of their execution process, they may be associated with the threads within the preset group through resource constraints. Therefore, in some embodiments, in order to further reduce the lag phenomenon in the interaction scenario, the threads that have a constraint relationship with the threads directly related to the user interaction event can also be added to the preset group. It can be understood that once this constraint relationship ends, this thread needs to be removed from the preset group. Among them, the specific constraint relationships include but are not limited to inter-process communication, inter-thread communication, or holding critical resources, etc. For example, the ordinary threads requested by the threads within the preset group through inter-process communication, the ordinary threads that hold critical resources such as wait semaphores, read-write semaphores, and mutexes required by the threads within the preset group, etc. In the embodiments of the present application, such threads are also added to the preset group.

[0080] If the first thread belongs to the preset group, then the scheduling priority of the first IO request is increased, or rather, the software processing priority of the first IO request is increased, or rather, the scheduling priority of the first IO request is set to the highest level supported by the IO scheduler.

[0081] In a possible implementation (denoted as Method 1), the scheduling priority of the first I / O request can be improved by modifying the attribute information of the first thread. For example, two scheduling priority levels can be set in total: high priority and low priority. Among them, the I / O requests corresponding to the threads scheduled in real time are all of high priority, and the I / O requests corresponding to the non-real-time scheduled threads are all of low priority. Therefore, the scheduling priority of the first I / O request can be improved by setting the first thread as a thread scheduled in real time (such as an RT thread). Another example is that two scheduling priority levels can be set in total: high priority and low priority. An identification bit for indicating the scheduling priority is set in the attribute parameters of the first I / O request. When the identification bit takes the value of 1, it indicates that the first I / O request is of high priority, and when the identification bit takes the value of 0, it indicates that the first I / O request is of low priority. Therefore, the scheduling priority of the first I / O request can be improved by setting the identification bit to 1.

[0082] In another possible implementation (denoted as Method 2), a fourth tag can be added to BIO#1 to indicate that the scheduling priority of the first I / O request is high priority.

[0083] S206. The recognition module checks the priority level of the first thread.

[0084] S207. If the first thread is a real-time thread, add a second tag to BIO#1.

[0085] Exemplarily, the recognition module checks the original priority level of the first thread based on BIO#1. If the first thread is originally a real-time thread, it means that it is originally a high-priority thread. At this time, the hardware processing priority of the first I / O request can be improved. For example, a second tag is added to the structure of BIO#1. The second tag can be an identification bit, and the second tag is used to indicate to elevate the hardware processing priority of the first I / O request, or rather, the second tag is used to indicate to set the hardware processing priority of the first I / O request to the highest level, or rather, the second tag is used to indicate that the hardware device (i.e., the memory at the hardware layer) gives priority to processing the first I / O request.

[0086] If the first thread is originally a non-real-time thread, it means that the first thread is originally a low-priority thread. After improving the scheduling priority of the first I / O request according to the process shown in S250, the hardware processing priority of the first I / O request is no longer adjusted. At this time, step S207 can be skipped and step S208 can be directly executed (at this time, the BIO#2 sent by S208 is the same as BIO#1).

[0087] That is to say, the method provided by the embodiment of the present application divides the processing process of the first IO request into a software processing process and a hardware processing process, and sets a scheduling priority and a hardware processing priority for these two processes respectively. Among them, the software processing process refers to the process in which the IO scheduler dispatches the IO request, and for specific reference, please refer to the description in the subsequent step S209. The hardware processing process refers to the process in which the memory processes the IO request, and for specific reference, please refer to the description in the subsequent step S212. In terms of specific implementation, the software priority and the hardware priority of the first IO request can be set according to information such as the IO category of the first IO request, the group to which the thread belongs, and the priority level of the thread itself. The following combines Figure 3 with the process 300 in

[0088] to make an exemplary description of this process.

[0089] It can be understood that the present application does not limit the execution order of steps S203 to S207. That is to say, the execution order in the above example is only an example, and the decision module can execute steps S203 to S205 in any order. For example, the decision module can first determine whether the first thread belongs to a preset group. If it belongs, it continues to check the IO type of the first IO request. When the IO type of the first IO request is a read operation, the scheduling priority of the first IO request is increased. At this time, it can be further determined whether the first thread is a real-time thread. If so, a second label is added to the structure of BIO#1 to increase the hardware processing priority of the first IO request.

[0090] S208. The recognition module sends BIO#2 to the IO scheduler.

[0091] Exemplarily, the recognition module sends BIO#2 to the IO scheduler based on the received BIO#1.

[0092] It can be understood that if the IO type of the first IO request is other than a read operation, BIO#2 is the same as BIO#1, that is, the recognition module will directly forward the received BIO#1 to the IO scheduler.

[0093] If the IO type of the first IO request is a read operation and the recognition module improves the scheduling priority of the first IO request by the first method described in step S205, then the attribute information of the first thread carried by BIO#2 has been modified; if the recognition module improves the scheduling priority of the first IO request by the second method described in step S205, then BIO#2 carries a fourth tag.

[0094] Furthermore, if the first thread is a real-time thread, BIO#2 also carries a second tag.

[0095] S209. The IO scheduler dispatches IO requests according to the software priority.

[0096] Exemplarily, after receiving BIO#2, the IO scheduler dispatches the first IO request based on BIO#2.

[0097] In a possible implementation, the IO scheduler manages multiple software queues, and different software queues correspond to different scheduling priorities. The IO scheduler can place high-priority IO requests in a high-priority queue for scheduling processing and place low-priority IO requests in a low-priority queue for scheduling processing.

[0098] For example, the IO scheduler manages two software queues, denoted as the first software queue and the second software queue respectively, where the scheduling priority of the first software queue is higher than that of the second software queue, that is, the first software queue is a high-software-priority queue and the second software queue is a low-software-priority queue. After receiving BIO#2, the IO scheduler can determine whether to add the first IO request to the first software queue or the second software queue according to the information carried in BIO#2. Specifically, when the attribute information carried in BIO#2 indicates that the first thread corresponding to the first IO request is a real-time thread, or when BIO#2 carries a fourth tag, it means that the first thread belongs to a preset group and the IO type of the first IO request is a read operation. Therefore, the IO scheduler determines to process the first IO request preferentially and thus adds the first IO request to the first software queue.

[0099] It can be understood that the IO scheduler will preferentially schedule (or dispatch) the IO requests in the first software queue to reduce the time-consuming of high-priority IO requests in software scheduling. The specific scheduling method is not limited in this application, and several possible implementation methods are exemplarily described below.

[0100] In the first possible implementation, the IO scheduler can first dispatch the IO requests in the first software queue. After all the IO requests in the first software queue have been dispatched and processed, the IO requests in the second software queue are then dispatched. This way can maximize the priority dispatch and processing of the IO requests in the first software queue, and reduce the situation where the IO requests in the first software queue are delayed due to the processing of the IO requests in the second software queue.

[0101] In the second possible implementation, the IO scheduler can first dispatch the IO requests in the first software queue. After all the IO requests in the first software queue have been dispatched, it starts to dispatch the IO requests in the second software queue, but it is necessary to control the number of dispatched but uncompleted IO requests in the second software queue to achieve bandwidth control. The following will make an exemplary description of this implementation mode in combination with Figure 4 the process 400 in

[0102] B1. The IO scheduler selects an IO request for dispatch.

[0103] Exemplarily, the IO scheduler manages the first software queue and the second software queue. The first software queue includes one or more IO requests with high software priorities, and the second software queue includes one or more IO requests with low software priorities. The IO scheduler selects an IO request for dispatch from the first software queue or the second software queue.

[0104] B2. Determine whether the first software queue is empty.

[0105] B3. Dispatch the IO requests in the first software queue.

[0106] Exemplarily, in this example, the principle for the IO scheduler to dispatch IO requests is to first dispatch the IO requests with high software priorities. Therefore, the IO scheduler needs to determine whether the first software queue is empty. If it is not empty, it means that the IO requests with high software priorities in the first software queue have not been completely dispatched. Therefore, the IO scheduler continues to dispatch the IO requests in the first software queue. It is not until the first software queue is empty, that is, after all the IO requests with high software priorities have been dispatched, that step B4 is executed.

[0107] B4. Calculate the first quantity.

[0108] Exemplarily, after determining that the first software queue is empty, the IO scheduler calculates the first quantity (denoted as Sum non-rt ), and this Sum non-rtis the number of low-software-priority IO requests that have been scheduled and dispatched but not yet processed. For convenience, the low-software-priority IO requests are denoted as the second IO requests, and the threads corresponding to the second IO requests are the second threads. Therefore, the second threads do not belong to the preset group, or the IO type of the second IO requests is a non-read operation. The number of second IO requests refers to those that have been dispatched from the IO scheduler but have not yet been processed by the memory, or are still in the hardware queue maintained by the memory. Sum non-rt The value can be used to indicate the number of second IO requests to be processed in the hardware queue.

[0109] B5. Determine whether the first quantity is greater than the first threshold.

[0110] B6. Dispatch the IO requests in the second software queue.

[0111] Exemplarily, to achieve bandwidth control, it is not desirable for the number of second IO requests to be processed in the hardware queue to be too high, because if this number is too high, it may affect the dispatch and processing of the IO requests in the first software queue.

[0112] On the one hand, the software priority of some IO requests has been improved, but the hardware priority has not been improved. Although these IO requests belong to the first software queue, when processed on the hardware side, they are processed together with the IO requests in the second software queue (i.e., the second IO requests). If there are too many second IO requests in the hardware queue, then the processing latency of some of the IO requests dispatched from the first software queue will be relatively large. Therefore, we do not want there to be too many second IO requests to be processed in the hardware queue.

[0113] On the other hand, if the number of second IO requests to be processed in the hardware queue is too high, the time for the hardware side to process these second IO requests will be relatively long. At this time, new high-priority IO requests may have been re-added to the software queue. Even if the high-priority IO requests are dispatched first, it is very likely that they will not be processed first because the hardware is busy processing the second IO requests at this time, and this process usually cannot be interrupted. Therefore, the subsequently dispatched high-priority IO requests may need to wait until the low-priority second IO requests are processed before they can be processed, thus increasing the processing latency.

[0114] On the other hand, the vast majority of IO requests are low-priority IO requests. That is to say, the number of IO requests in the second software queue is usually much larger than that in the first software queue. If all the low-priority IO requests are dispatched to the hardware side at once, it may cause excessive bandwidth pressure, may lead to task blocking, and may even cause the database to crash in severe cases.

[0115] Therefore, in the embodiments of the present application, it is necessary to first determine whether the first quantity is greater than the first threshold. If not, it means that the quantity of the second IO requests that have been dispatched and are pending processing is within an acceptable range. At this time, step B6 can be executed, that is, dispatch the IO requests in the second software queue. In a possible implementation manner, when executing step B6, the dispatch can be performed according to the difference between the first quantity and the first threshold. For example, if the first threshold is 20 and the first quantity is 8, then 12 second IO requests can be dispatched at one time to achieve bandwidth control. After one dispatch, it is possible to determine again through the processes of B4 and B5 whether to perform the next dispatch. In this way, it is not necessary to wait for all the IO requests in the first software queue to be processed before dispatching the IO requests in the second software queue, thereby reducing the waiting time of the second IO requests, reducing the waiting duration of the second IO requests, and improving the dispatch efficiency of the IO requests.

[0116] It can be understood that the above first quantity can be a preconfigured value. Specifically, the first threshold can be the ratio of the maximum hardware resources to the control coefficient, where the maximum hardware resources refer to the maximum resource quantity supported by the hardware side (such as the memory), and the control coefficient can be any preconfigured value greater than 1.

[0117] Optionally, in an implementation manner, if it is determined in step B5 that the first quantity is greater than the first threshold, at this time, the dispatch of the IO requests in the second software queue can be suspended, or step B7 can also be continued to be executed.

[0118] B7. Determine whether all the IO requests in the first software queue have been processed.

[0119] B8. Dispatch the IO requests in the second software queue.

[0120] B9. Suspend the dispatch of the IO requests in the second software queue.

[0121] Exemplarily, if the first quantity is greater than the first threshold, it is possible to continue to determine whether all the IO requests in the first software queue have been processed. If all have been processed (that is, all the IO requests in the first software queue have been dispatched and all have been processed), at this time, there is no need to worry about the problem that the processing delay of some IO requests in the first software queue becomes larger due to the excessive number of second IO requests pending processing in the hardware queue. Therefore, step B8 can be directly executed, that is, dispatch the IO requests in the second software queue.

[0122] If some of the IO requests in the first software queue have not been processed yet (that is, all the IO requests in the first software queue have been dispatched, but some or all have not been processed yet), at this time, the dispatch of the IO requests in the second software queue can be suspended until all the IO requests in the first software queue have been processed and then dispatched.

[0123] In the third possible implementation, scheduling can be performed by combining the priority and the time when the IO request is triggered, which can not only give priority to dispatching the IO requests in the first software queue, but also reduce the situation where the IO requests in the second software queue are blocked due to long-term processing, resulting in the "starvation" of the corresponding threads. An exemplary description of a possible implementation is given below.

[0124] For example, the IO scheduler can determine its sorting based on the scheduling priority corresponding to the IO request and the trigger time of the IO request (i.e., the time when the IO scheduler receives the BIO corresponding to the IO request). Specifically, for the IO request in the first software queue (taking the first IO request as an example) and the IO request in the second software queue (taking the second IO request as an example), if the time difference between the trigger times of the first IO request and the second IO request is less than or equal to the second threshold, the first IO request is preferentially dispatched; if the time difference between the trigger times of the first IO request and the second IO request is greater than the second threshold, the second IO request is preferentially dispatched. That is to say, the principle of preferentially dispatching the first IO request is still followed, but if the trigger time of the second IO request is much earlier than the trigger time of the first IO request, in order to prevent the "starvation" of the thread corresponding to the second IO request, the second IO request can be dispatched first. Based on such a principle, the situation where the second IO request is blocked for a long time can be minimized.

[0125] For another example, the scheduling waiting duration corresponding to each I / O request can be determined according to the scheduling priority corresponding to the I / O request and the trigger time of the I / O request (i.e., the time when the I / O scheduler receives the BIO corresponding to the I / O request). Among them, the scheduling waiting duration is negatively correlated with the scheduling priority and positively correlated with the trigger time of the I / O request. That is to say, for the same scheduling priority, the earlier the trigger time of the I / O request, the shorter the scheduling waiting time; for the same trigger time of the I / O request, the higher the scheduling priority, the shorter the scheduling waiting time. In specific implementation, it can be achieved through a scoring system. For example, each I / O request corresponds to a total score, including a priority score and a trigger time score. A high priority, for example, is 0.5 points, a low priority, for example, is 0 points, and the trigger time score is the reciprocal of the time difference between the trigger time and the origin time. The origin time can be any arbitrarily set time point. The higher the total score, the higher the priority for processing. Specifically, for example, assume that the first I / O request has a high software priority, and the time difference between its trigger time and the origin time is 10 ms, then the total score corresponding to the first I / O request is 0.5 + 1 / 10, that is, 0.6; assume that the second I / O request has a low software priority, and the time difference between its trigger time and the origin time is 5 ms, then the total score corresponding to the second I / O request is 0 + 1 / 5 = 0.2; assume that the third I / O request has a low software priority, and the time difference between its trigger time and the origin time is 0.2 ms, then the total score corresponding to the third I / O request is 0 + 1 / 0.2 = 5. Therefore, the scheduling order of the above three I / O requests is: the third I / O request, the first I / O request, and the second I / O request. It should be understood that the specific scoring method can be formulated according to actual business needs. Here, only an example is given, which does not uniquely limit this solution. In this way, the I / O requests in the first software queue can be processed preferentially as much as possible, and it can also prevent the situation that when a large number of I / O requests in the first software queue are concurrent, the I / O requests in the second software queue will be blocked all the time.

[0126] S210. The I / O scheduler sends a request to the device driver.

[0127] Exemplarily, the I / O scheduler converts BIO#2 into a message in the request structure (denoted as request), and sends the request to the device driver.

[0128] It can be understood that if a second tag is carried in BIO#2, the I / O scheduler will carry a third tag in the request message, and the third tag is used to indicate to increase the hardware processing priority of the first I / O request. The third tag can be the same as or different from the second tag, which is not limited in this application.

[0129] S211. The device driver sends a cmd to the memory.

[0130] Exemplarily, after the device driver (such as the universal flash storage (UFS) driver layer) receives a request from the I / O scheduler, it generates a corresponding cmd and sends it to the memory in the hardware layer. This cmd is used to instruct the memory to process the first I / O request.

[0131] It can be understood that if the third tag is carried in the request, the device driver will add the first tag to the cmd and pass it to the memory. This first tag is used to instruct the memory to give priority to processing the first I / O request.

[0132] As an example, the device driver can modify the original descriptor in the cmd to add this first tag to the descriptor.

[0133] S212. The memory processes the I / O requests according to the hardware priority.

[0134] Exemplarily, after the memory receives the cmd, it processes the first I / O request based on the cmd.

[0135] Specifically, for example, the memory manages multiple hardware queues and can place the first I / O request in one of the hardware queues according to a preset rule. For example, the memory manages 8 hardware queues (denoted as queue 0 to queue 7), and each hardware queue corresponds to a CPU (denoted as CPU0 to CPU7). Assume that the first thread is a thread on CPU0, and CPU0 corresponds to queue 0. After receiving the first I / O request, the first I / O request is added to queue 0 for processing.

[0136] After adding the first I / O request to the hardware queue (such as the above-mentioned queue 0), the I / O requests in this hardware queue are processed according to the hardware priority.

[0137] In a possible implementation, the memory sorts the I / O requests with high hardware priority in chronological order and then places the I / O requests with high hardware priority at the front of the hardware queue; and sorts the I / O requests with low hardware priority in chronological order and then places the I / O requests with low hardware priority at the back of the hardware queue. That is to say, for I / O requests with the same priority level, they are processed in the order of "first come, first served", and for I / O requests with different priority levels, the I / O requests with high hardware priority are processed first, and then the I / O requests with low hardware priority are processed. Therefore, in the above example, when the first tag is carried in the cmd, the memory processes the first I / O request according to the highest priority supported by the hardware queue, that is, places the first I / O request at the front of the hardware queue; when the first tag is not carried in the cmd, the memory processes the first I / O request according to the lowest priority supported by the hardware queue, that is, places the first I / O request at the back of the hardware queue.

[0138] In another possible implementation, the above-mentioned hardware queue further includes two hardware sub-queues, and different hardware sub-queues correspond to different hardware processing priorities. The memory can place high-priority IO requests in the high-priority hardware sub-queue for processing, and place low-priority IO requests in the low-priority hardware sub-queue for processing. For example, the memory adds the first IO request to queue 0 according to a preset rule. Queue 0 includes two hardware sub-queues, denoted as the first hardware sub-queue and the second hardware sub-queue respectively, where the processing priority of the first hardware sub-queue is higher than that of the second hardware sub-queue, that is, the first hardware sub-queue is the high-priority hardware sub-queue, and the second hardware sub-queue is the low-priority hardware sub-queue. The memory can determine whether to add the first IO request to the first hardware sub-queue or the second hardware sub-queue according to the information carried in the cmd. Specifically, when the first tag is carried in the cmd, the memory determines to give priority to processing the first IO request, so the first IO request is added to the first hardware sub-queue; when the first tag is not carried in the cmd, the memory determines not to give priority to processing the first IO request, so the first IO request is added to the second hardware sub-queue.

[0139] It can be understood that the memory will give priority to processing the IO requests in the first hardware sub-queue to reduce the time-consuming of high-priority IO requests in hardware processing. This application does not limit the specific processing method. As an example, in a possible implementation, the memory can first process the IO requests in the first hardware sub-queue. After all the IO requests in the first hardware sub-queue are processed, then process the IO requests in the second hardware sub-queue. This method can maximize the priority processing of the IO requests in the first hardware sub-queue and reduce the situation where the IO requests in the first hardware sub-queue are delayed due to processing the IO requests in the second hardware sub-queue. In another possible implementation, it can be processed comprehensively according to the priority and the time when the IO request is triggered (that is, the time when the memory receives the cmd), which can not only give priority to processing the IO requests in the first hardware sub-queue, but also reduce the situation where the IO requests in the second hardware sub-queue are "starved" due to being blocked in the long-term processing state. The specific implementation method is similar to the third possible implementation method introduced in part 209, the difference is that in step 209, the IO scheduler dispatches the IO requests in different software queues, while in step 212, the memory processes the IO requests in different hardware queues, and the specific process will not be elaborated here.

[0140] In summary, the embodiment of this application provides a method for processing input / output (IO) requests, which can preferentially schedule and process some threads that may affect the user interaction experience, so as to reduce the lag of the user interface during user interaction and improve the user experience.

[0141] Specifically, in this method, multiple groups are pre-divided for threads. Taking the example given in (a) of Figure 5 as an example, the threads are divided into four groups in total, denoted as Group 1, Group 2, Group 3, and Group 4 respectively. Then at least one of the groups is preset as a critical group (denoted as the preset group). Assume that Group 1 is the preset group. In one implementation, the threads in Group 1 are the threads that execute tasks related to user interaction events, and these threads are closely related to the user experience. In order to reduce the stuttering during user interaction, the scheduling priority of the IO requests of the read operation type triggered by the threads in the preset group can be improved. As Figure 5 shown, the IO scheduler manages two queues, namely the first software queue and the second software queue. Among them, the scheduling priority of the first software queue is higher than that of the second software queue, and each square in the queue represents a processing task of an IO request. The black squares in Group 1 are the processing tasks corresponding to the IO requests of the read operation type. Therefore, the IO scheduler adds the tasks represented by the black squares in Group 1 to the first software queue, and adds the squares of other colors in Group 1 and the squares of other groups to the second software queue. During specific scheduling, the IO requests in the first software queue can be preferentially scheduled, so as to reduce the scheduling delay of the IO requests of the read operation type in the preset group.

[0142] Optionally, for the real-time threads in the preset group, tags can be added to the IO requests and passed to the memory through the block layer and the device driver to indicate that the memory preferentially processes the real-time threads in the preset group, thereby reducing the processing delay of these threads and reducing the blocking time when the thread of the application requests an IO operation during overload. As Figure 5 shown in (a) of Figure 5The first hardware sub-queue and the second hardware sub-queue shown in (b) therein, where the processing priority of the first hardware sub-queue is higher than that of the second hardware sub-queue. After receiving the cmds corresponding to different IO requests from the device driver layer, the devices in the hardware layer add the tasks of the IO requests with tags to the first hardware sub-queue and add the tasks of other IO requests to the second hardware sub-queue, thereby reducing the processing delay of the IO requests of the read operation type of the real-time threads within the preset group.

[0143] Figure 6 FIG. shows a schematic flowchart of a method 600 for processing input / output requests provided by an embodiment of the present application. The method 600 can be executed by an electronic device. As a specific example, the method 600 can be executed by the kernel layer in the electronic device. For example, the method 600 is executed by the kernel layer including modules such as a file system, an identification module, an IO scheduler, a device driver, etc. as shown in Figure 1 In a specific example, step S610 in method 600 can be executed by the file system of the kernel layer, step S620 can be executed by the identification module of the kernel layer, and step S630 can be executed by the IO scheduler of the kernel layer. It should be understood that method 600 can correspond to method 200. At this time, the specific solutions in method 600 correspond to the specific processes executed by the kernel layer in method 200. Therefore, the descriptions of the solutions in method 200 can all be applied to method 600, and the solutions not detailed in method 600 can refer to the content in method 200.

[0144] S610, receive a first input / output request of a first thread.

[0145] S620, determine whether the first thread is a thread within a preset group.

[0146] Exemplarily, after receiving a first input / output (IO) request of a first thread, determine whether the first thread belongs to a thread within a preset group.

[0147] In a possible implementation manner, the identification information of the preset group can be pre-configured in the electronic device. After receiving the first input / output request, according to the pre-configured information and the group information of the first thread, determine whether the first thread is a thread within the preset group. That is, the identification information of the preset group is pre-configured for the electronic device. When the identification information of the group carried in the received first IO request matches the identification information of the preset group, it indicates that the first thread belongs to the preset group.

[0148] In another possible implementation, according to the attribute information of the first thread, it is determined whether the first thread is a thread within the preset group. That is to say, after receiving the first IO request, it can be temporarily determined whether the first thread belongs to the preset group according to the attribute information of the first thread. Specifically, the judgment criteria can be pre-configured and then the judgment can be made based on this criteria. For example, when the first thread is a UI thread, a Render thread, a GL thread, or a thread having a dependency relationship with a UI thread, a Render thread, or a GL thread, it is determined that the first thread belongs to the preset group.

[0149] This application does not limit the category of threads within the preset group, that is, this application does not limit the way of grouping threads. In a possible example, the threads within the preset group are threads that execute tasks related to user interaction events.

[0150] S630, in the case where the first thread is a thread within the preset group, add the first IO request to the first software queue in the software queue set for scheduling processing.

[0151] Exemplarily, if the first thread belongs to the preset group, it means that the first thread is likely to affect the smoothness of the user's interaction interface with the electronic device. Therefore, the first thread is added to the first software queue in the software queue set managed by the electronic device, where the scheduling priority of the first software queue is higher than the scheduling priority of other software queues (such as the second software queue) in this software queue.

[0152] Optionally, before executing S603, the IO type of the first IO request can also be checked. Only when it is determined that the IO type of the first IO request is a read operation, S630 is executed. That is to say, if the IO type of the first IO request is a non-read operation (i.e., other types of IO operations other than the read operation), S630 is not executed.

[0153] When scheduling the first I / O request, a control command is sent to the hardware layer to instruct the memory in the hardware layer to process the first I / O request. At the same time, a first tag can be added to the first control command. The first tag is used to indicate that after the memory adds the first I / O request to the hardware queue, the first I / O request is processed according to the highest priority supported by the hardware queue, that is, the first tag is used to indicate that the memory gives priority to processing the first I / O request. The specific process is as follows: for example, the recognition module obtains the first BIO from the file system and adds a second tag to the first BIO to obtain the second BIO. The first BIO is a file in the BIO structure based on the input / output request; then, the I / O scheduler obtains the second BIO from the recognition module and adds a third tag to the request message based on the second tag. The request message is a message in the request structure based on the second BIO; finally, the hardware driver obtains the request message from the I / O scheduler and adds the first tag to the control command based on the third tag.

[0154] Optionally, before adding the first tag to the first control command, it can be determined whether the first thread is a real-time thread. Only if the first thread is a real-time thread, the first tag is added to the control command.

[0155] Based on the above solution, the problem that the key I / O is blocked and the interactive interface lags in the overload scenario can be alleviated. For example, when the electronic device performs mirror merge or memory page swapin after OTA upgrade, or during the application startup process, a large number of I / O requests will be concurrent, and the background / burst load will become higher, which may exceed the processing capacity of the device, resulting in a large number of I / O requests being blocked. Some I / O requests that are sensitive to latency cannot be processed in time, which may cause the interactive interface to lag. Through the solution provided in this application, the I / O requests within the preset group can be preferentially scheduled and processed, thereby alleviating the problem that the user interface lags due to I / O blockage during user interaction.

[0156] Corresponding to the methods given in the above method embodiments, the embodiments of the present application also provide corresponding electronic devices. Figure 7 The structural schematic diagram of the electronic device 700 provided by the embodiment of the present application is shown. The electronic device 700 includes: at least one processor 710, a memory 720, and a computer program 721 stored in the memory and executable on the at least one processor. When the processor executes the computer program, the steps in any of the above method embodiments are implemented.

[0157] It should be noted that for the information interaction, execution process, etc. between the above-mentioned modules / units, since they are based on the same concept as the method embodiments of the present application, their specific functions and the technical effects brought about can be specifically referred to in the method and system embodiment parts, and will not be elaborated here.

[0158] In an implementation manner of the present application, Figure 7 the electronic device 700 in Figure 1 can correspond to the system architecture 100 in Figure 1 As an example, the functions of the file system, recognition module, block layer (including the IO scheduler), and device driver in Figure 7 can be similar to the functions implemented by the processor 710 in Figure 7 The memory 720 in Figure 1 can be similar to the functions of the memory in the hardware layer in

[0159] The embodiments of the present application also provide a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments can be implemented.

[0160] The embodiments of the present application provide a computer program product. When the computer program product runs on a device, the device is caused to execute the steps in the above-mentioned method embodiments.

[0161] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, to implement all or part of the processes in the above-mentioned method embodiments of the present application, a computer program can be used to instruct the relevant hardware to complete. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments can be implemented. Among them, the computer program includes computer program code, and the computer program code can be in the form of source code, object code, executable file or some intermediate form, etc. The computer-readable medium can at least include: any entity or device that can carry the computer program code to the photographing device / electronic device, recording medium, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signal, telecommunication signal, and software distribution medium. For example, a USB flash drive, a mobile hard disk, a magnetic disk or an optical disc, etc. In some jurisdictions, according to legislation and patent practice, the computer-readable medium cannot be an electrical carrier signal and a telecommunication signal.

[0162] In the above embodiments, the descriptions of the various embodiments each have their own emphasis. For parts not described in detail or recorded in a certain embodiment, reference may be made to the relevant descriptions of other embodiments.

[0163] Those of ordinary skill in the art can realize that the units and algorithm steps of the examples described in combination with the embodiments disclosed herein can be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. A professional technician can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of this application.

[0164] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them; although this application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements for some of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

[0165] In addition, it should be noted that various numerical numbers involved in this application (such as the terms "first", "second", "third", "fourth" and other various term numbers in the specification, claims and the above drawings (if any)) are only for the convenience of description for distinction, and are not used to limit the scope of this application. The magnitude of the serial numbers of the various processes does not mean the sequence of execution, and the execution sequence of the various processes should be determined by their functions and internal logic.

[0166] The terms "comprise" and "have" and any variations thereof mean "including but not limited to", unless otherwise specifically emphasized. For example, a process, method, system, product or device that includes a series of steps or units does not necessarily have to be limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0167] In the embodiments of this application, words such as "exemplarily" or "for example" are used to indicate examples, illustrations or explanations. Any embodiment or design solution described as "exemplarily" or "for example" in the embodiments of this application should not be construed as being more preferred or having more advantages than other embodiments or design solutions. Rather, the use of words such as "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner.

[0168] In various embodiments of the present application, if there is no special description or logical conflict, the terms and / or descriptions between different embodiments are consistent and can be mutually referred to. The technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationships. The specific operation methods in the method embodiments of the present application can also be applied to the apparatus embodiments or system embodiments.

[0169] In the embodiments of the present application, the "storage" or "saving" involved may refer to being stored in one or more memories. The one or more memories may be separately provided or integrated in an encoder, a decoder, a processor, or an electronic device. The one or more memories may also be partially separately provided and partially integrated in a decoder, a processor, or an electronic device. The type of the memory may be any form of storage medium, and the present application does not limit this.

Claims

1. A method for processing input / output requests, characterized in that, The method includes: Receiving a first input / output (IO) request of a first thread; Determining whether the first thread is a thread within a preset group; When the first thread is a thread within the preset group, adding the first IO request to a first software queue in a software queue set for scheduling processing, where the software queue set further includes a second software queue, and the scheduling priority of the first software queue is higher than that of the second software queue.

2. The method according to claim 1, wherein The preset group includes threads that execute tasks related to user interaction events.

3. The method according to claim 1 or 2, characterized in that, The determining whether the first thread is a thread within the preset group includes: Determining whether the first thread is a thread within the preset group according to pre-configured information and the grouping information of the first thread; or Determining whether the first thread is a thread within the preset group according to the attribute information of the first thread.

4. The method according to claim 1 or 2, characterized in that, Before adding the first IO request to the first software queue in the software queue set for scheduling processing, the method further includes: Determining that the IO type of the first IO request is a read operation.

5. The method according to claim 1 or 2, characterized in that, The method further includes: Adding a first tag to a control command; Sending the control command to a hardware layer, where the control command is used to instruct a memory within the hardware layer to process the first IO request, and the first tag is used to instruct the memory to process the first IO request with the highest priority supported by the hardware queue after adding the first IO request to the hardware queue.

6. The method according to claim 5, wherein The adding the first tag to the control command includes: Determining whether the first thread is a real-time thread; When the first thread is a real-time thread, adding the first tag to the control command.

7. The method according to claim 5, characterized in that, The adding the first tag to the control command includes: Obtaining a first block input / output (BIO) from a file system through an identification module and adding a second tag to the first BIO to obtain a second BIO, where the first BIO is a file of a BIO structure based on the first IO request; Obtaining the second BIO from the identification module through an IO scheduler and adding a third tag to a request message based on the second tag, where the request message is a message of a request structure based on the second BIO; Obtaining the request message from the IO scheduler through a hardware driver and adding the first tag to the control command based on the third tag.

8. The method according to claim 1 or 2, characterized in that, After adding the first IO request to the first software queue in the software queue set for scheduling processing, the method further includes: When the first software queue is empty, obtaining a first quantity, where the first quantity is the quantity of second IO requests that have been scheduled and issued but not processed completely, and the second IO requests correspond to a second thread that does not belong to the preset group; When the first quantity is less than or equal to a first threshold, scheduling and issuing the second IO requests.

9. The method according to claim 8, characterized in that, When the first quantity is greater than the first threshold, the method further includes: Determining whether all the IO requests scheduled out from the first software queue have been processed completely; When all the I / O requests dispatched from the first software queue have been processed, dispatch the second I / O request; or, Stop dispatching the second I / O request.

10. An electronic device, characterized in that, The structure of the electronic device includes a processor and a memory; The memory is used to store a program that supports the electronic device to execute the method provided in any one of claims 1 to 9, and to store data involved in implementing the method described in any one of claims 1 to 9; The processor is configured to execute the program stored in the memory.

11. A computer-readable storage medium, characterized in that, Instructions are stored in the computer-readable storage medium, and when they run on a computer, cause the computer to execute the method described in any one of claims 1 to 9.

Images