CN115729684B

CN115729684B - Input/output request processing method and electronic equipment

Info

Publication number: CN115729684B
Application number: CN202211362704.4A
Authority: CN
Inventors: 李鹏; 田野
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2021-08-25
Filing date: 2021-08-25
Publication date: 2023-09-19
Anticipated expiration: 2041-08-25
Also published as: CN114443240B; CN115729684A; CN114443240A

Abstract

The application provides an input/output request processing method and electronic equipment. The method can be applied to electronic equipment such as mobile phones and tablet computers which have the capacity and need frequent read-write operations. By implementing the method, the electronic equipment can detect the average response time of IO requests with different priorities in real time. When the average response time of the IO requests with high priority is higher than that of the IO requests with low priority, the electronic equipment can improve the IO allocation proportion of the high priority group and reduce the IO allocation proportion of the low priority group. In this way, in the same time, the electronic device can process more IO requests with high priority, so that the number of waiting IO requests with high priority is reduced, the average response time of IO requests with higher priority is ensured to be lower than that of IO requests with low priority, more IO resources are provided for foreground application, blocking is avoided, and user experience is improved.

Description

Input/output request processing method and electronic equipment

The present application is a divisional application, the application number of which is 202110983851.2, the application date of which is 25 th 08 th 2021, the entire contents of which are incorporated herein by reference.

Technical Field

The present application relates to the field of terminals, and in particular, to a method for processing an input/output request and an electronic device.

Background

In the scenario of running a plurality of application programs, a read-write scheduling module of electronic devices such as a mobile phone, a tablet computer and the like can receive a plurality of read operation requests or write operation requests issued by the application programs, namely input-output requests (i.e. IO requests for short).

The existing priority-based IO request scheduling method guarantees that the bottom layer device responds to the IO request issued by the foreground application preferentially, and improves the efficiency of the bottom layer device responding to the IO request of the foreground application to a certain extent. However, due to the time consuming effects of other operations, such as encryption, decryption, compression, decompression, data verification, etc., that are attendant to the different types of read and write operations, the response time of high priority IO requests is still higher than that of low priority IO requests.

That is, the mere priority-based IO request scheduling method cannot guarantee that the high-priority IO requests must have a low average response time. That is, in the case of preferentially processing the high-priority IO request issued by the foreground application, occupation of the IO resource by the application running in the background still has a large influence on the foreground application.

Disclosure of Invention

The application provides an input/output request processing method and electronic equipment. The electronic equipment implementing the input/output IO request processing method can detect the processing time of the IO business with different priorities by the electronic equipment in real time. When the processing time of the high-priority IO service is longer than that of the low-priority IO service, the electronic equipment can increase the occupancy rate of the high-priority IO service to IO resources, so that the processing efficiency of the high-priority IO service is improved, and blocking is avoided.

In a first aspect, an embodiment of the present application provides an input/output IO processing method, where the method is applied to an electronic device, and the method includes: at the first time, a plurality of IO services are taken out from a plurality of queues; one queue is used for storing one or more IO services with the same IO processing priority, and the IO processing priorities of the IO services stored in different queues are different; IO processing is carried out on the plurality of extracted IO services according to the IO processing priority; determining processing time delay of a plurality of IO services in IO processing, wherein the processing time delay of one IO service is used for indicating time consumption of the IO service when the application program receives an IO processing result of one IO service from the arrival of one IO service; a second time, a plurality of IO services are taken out from a plurality of queues; the second time is after the first time; if the processing time delay of the IO service with high IO processing priority is longer than the processing time delay of the IO service with low IO processing priority, the ratio of the high-priority IO service in the plurality of IO services taken out at the second time is higher than that of the high-priority IO service in the plurality of IO services taken out at the first time.

By implementing the method provided by the first aspect, the electronic equipment can detect the IO service processing time of the electronic equipment with different priorities in real time. When the processing time of the high-priority IO service is longer than that of the low-priority IO service, the electronic device can increase the occupancy rate of the high-priority IO service to IO resources, so that the electronic device can process more high-priority IO requests within the same time, the processing efficiency of the high-priority IO service is improved, and the response time is too long to influence the user experience.

With reference to the embodiments provided in the first aspect, in some embodiments, after the plurality of IO traffic is fetched from the plurality of queues at the second time, the method further includes: and after the processing result of the IO service with the low IO processing priority is retained for a first time, returning the processing result to the application program initiating the IO service with the low IO processing priority.

By implementing the method provided by the embodiment, the electronic device can reduce the activity of the application program with low delay requirements such as background application by limiting the return rate of the low-priority IO service, so that the electronic device can process the high-priority IO service more quickly.

With reference to the embodiment provided in the first aspect, in some embodiments, after the processing result of the low-priority IO request is retained for a first period of time, the processing result is returned to an application program that initiates the low-priority IO request, where the processing result specifically includes: determining the current load of a Central Processing Unit (CPU) of the electronic equipment; and if the current load is higher than a first threshold, after the processing result of the low-priority IO request is retained for a first time, returning the processing result to the application program initiating the low-priority IO request, wherein the first threshold is preset.

By implementing the method provided by the embodiment, the electronic device can judge whether the return rate of the priority IO service needs to be limited or not through the current load of the CPU. When the current load of the CPU is too high, even if the IO resources occupied by the IO service with high priority are enough, the CPU resources cannot be processed timely due to the fact that the CPU resources are insufficient. Therefore, at this time, the electronic device can limit the return rate of the priority IO service, and reduce the liveness of the application programs with low delay requirements such as background application, thereby ensuring that the high priority IO service has enough CPU resources.

With reference to the embodiment provided in the first aspect, in some embodiments, at a first time, the extracting a plurality of IO services from a plurality of queues specifically includes: at first time, a plurality of IO services are taken out from a plurality of queues according to a first ratio; and the second time, a plurality of IO services are taken out from a plurality of queues, specifically comprising: and at a second time, taking out a plurality of IO services from the plurality of queues according to a second ratio.

By implementing the method provided by the embodiment, the electronic device can acquire different numbers of IO services through the preset proportion, and the numbers of the IO services with different priorities are different from the different numbers of IO services acquired at one time. Thus, when the above-mentioned proportion adjustment is that, the electronic device can correspondingly acquire and adjust the number of IO services of which the acquired different priorities are different at one time.

In combination with the embodiments provided in the first aspect, in some embodiments, the number of proportional items of the first ratio is equal to the number of proportional items of the second ratio.

In combination with the embodiments provided in the first aspect, in some embodiments, a value of a first proportional term of the first ratio is lower than a value of a first proportional term of the second ratio, where the first proportional term is used to indicate a number of IO traffic acquiring a high IO processing priority.

Compared with the method for acquiring the IO services with different priorities according to the first ratio, the method provided by the embodiment of the invention can be implemented, when the electronic device acquires the IO services with different priorities according to the second ratio, the electronic device can acquire more IO services with high priority.

With reference to the embodiment provided in the first aspect, in some embodiments, the extracting a plurality of IO services from a plurality of queues according to a first ratio specifically includes: the number of the extracted plurality of IO services is equal to or greater than the sum of the numerical values of the proportion items of the first ratio, and the ratio of the number of IO services with different IO processing priorities in the extracted plurality of IO services is consistent with the first ratio; or, the number of the plurality of IO services is smaller than the sum of the numerical values of the proportion items of the first ratio.

By implementing the method provided by the embodiment, the number of the IO services with different priorities sequentially acquired by the electronic equipment can be equal to the number of each proportion term in the first proportion value; or the ratio of the first ratio to the second ratio is larger than the ratio of the first ratio to the second ratio; when the number of the IO services of a certain priority is less than the number indicated by the corresponding proportion item in the first ratio, the number of the IO services of the priority acquired by the electronic device may also be less than the number indicated by the corresponding proportion item in the first ratio.

With reference to the embodiments provided in the first aspect, in some embodiments, the processing delay specifically includes: the method comprises the steps that time consumption of receiving an IO processing result of an IO service from an application program when the arrival of the IO service is detected; or, from detecting the arrival of a plurality of one IO traffic, receiving the time-consuming average value of the IO processing results of the plurality of one IO traffic by the application program, wherein the plurality of one IO traffic is the IO traffic with the same IO processing priority as the one IO traffic.

By implementing the method provided by the embodiment, when judging whether the processing delay of the high-priority IO service is longer than the processing delay of the low-priority IO service, the electronic device can use the actual processing delay of the high-priority IO service to compare with the actual processing delay of the low-priority IO service, and can also use the average processing delay of all IO services of the priority to which the high-priority IO service belongs to compare with the average processing delay of all IO services of the priority to which the low-priority IO service belongs.

In a second aspect, the present application provides an electronic device comprising one or more processors and one or more memories; wherein the one or more memories are coupled to the one or more processors, the one or more memories being operable to store computer program code comprising computer instructions that, when executed by the one or more processors, cause the electronic device to perform the method as described in the first aspect and any possible implementation of the first aspect.

In a third aspect, the application provides a computer readable storage medium comprising instructions which, when run on an electronic device, cause the electronic device to perform a method as described in the first aspect and any possible implementation of the first aspect.

In a fourth aspect, the application provides a computer program product comprising instructions which, when run on an electronic device, cause the electronic device to perform a method as described in the first aspect and any possible implementation of the first aspect.

It will be appreciated that the electronic device provided in the second aspect, the computer storage medium provided in the third aspect, and the computer program product provided in the fourth aspect described above are all configured to perform the method provided by the present application. Therefore, the advantages achieved by the method can be referred to as the advantages of the corresponding method, and will not be described herein.

Drawings

Fig. 1 is a schematic diagram of a software architecture of an electronic device according to an embodiment of the present application;

fig. 2 is a schematic hardware structure of an electronic device according to an embodiment of the present application;

fig. 3A-3B are schematic software architecture diagrams of an electronic device according to an embodiment of the present application;

Fig. 4A-fig. 4B are schematic diagrams of an electronic device processing an IO request according to a scheduling policy according to an embodiment of the present application;

FIG. 4C is a flowchart of an electronic device determining a return control strategy according to an embodiment of the present application;

FIGS. 5A-5C are a set of user interface diagrams provided by an embodiment of the present application;

fig. 6 is a process flow diagram of an electronic device according to an embodiment of the present application.

Detailed Description

The terminology used in the following embodiments of the application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application.

Electronic devices such as mobile phones and tablet computers (hereinafter referred to as electronic device 100) can run multiple application programs simultaneously. The application may initiate an IO request. In response to the request, the electronic device 100 may perform a read-write operation corresponding to the IO request described above.

Fig. 1 illustrates a software architecture of an electronic device 100.

The software system of the electronic device 100 may employ a layered architecture, an event driven architecture, a microkernel architecture, a microservice architecture, or a cloud architecture. In the embodiment of the application, taking an Android system with a layered architecture as an example, a software structure of the electronic device 100 is illustrated.

The layered architecture divides the software into several layers, each with distinct roles and branches. The layers communicate with each other through a software interface. Generally, the layered architecture of Android includes: an application layer, a framework layer, a kernel layer, an Zhuoyun row (Android run) and a system library, etc. In an embodiment of the present application, the software architecture of the electronic device 100 shown in fig. 1 includes: an application layer, a kernel layer, and a device layer. The kernel layer includes a file system (file system) and a Block (Block).

Below the application layer and the kernel layer are device layers, i.e., hardware devices that respond to each IO request, including various types of storage devices, such as multimedia card (MMC)/embedded multimedia card (Embedded Multi media card, eMMC), SCSI (Small Computer System Interface) hard disk/universal flash storage (Universal Flash Storage, UFS), and so on.

The application layer may have a plurality of applications installed. Taking application 1 (APP 1) as an example, application 1 may initiate one or more IO requests in response to a user operation. One IO request indicates one IO operation. The IO requests include write requests (writes), read requests (reads), synchronization requests (fsync), write back (writeback) requests, forced buffer flush requests (flush), and so forth. For example, during video playing, an application program executing the video playing function may initiate a read request, and in response to the request, the application program may read video data stored in the storage, thereby playing the video.

The initiated IO request may go through the file system to the read-write scheduling layer (IO scheduler layer) in the Block (Block). Then, the read-write scheduling layer can sort IO requests in a waiting state in the layer according to a preset scheduling rule, and determine the priority of processing each IO request. Then, the storage device of the electronic device 100 may sequentially respond to the IO request according to the determined processing priority, and perform the input/output operation indicated by the IO request. The Block (Block) also includes a generic Block layer.

The read-write scheduling layer comprises: a read-write scheduling layer employing a Multi-queue (MQ) framework and a read-write scheduling layer employing a Single-queue (SQ) framework. In the embodiment of the application, the read-write scheduling layer can be a read-write scheduling layer under an MQ framework. In general, the read-write scheduling layer may perform scheduling of IO requests using an absolute fairness (Completely Fair Queueing) scheduling algorithm. In addition, the scheduling algorithm also includes a read-first (ROW) algorithm, and the like.

In order to improve the efficiency of the electronic device 100 in responding to the application program being operated by the user, the use experience of the user is improved, and the electronic device may mark the priorities of the read-write requests issued by different types of application programs. For example, the electronic device may mark a read-write request issued by an application program being operated by a user as a read-write request with a high priority, and a read-write request issued by an application program in a background running state as a request with a low priority. The application program operated by the user can be abbreviated as a foreground application; the application program in the background running state can be referred to as background application for short.

Then, the read-write scheduling layer can determine the sequence of the bottom layer device responding to the read-write requests issued by the application programs according to the priority of the read-write requests.

The IO request scheduling method based on the priority guarantees that the bottom layer equipment responds to the IO request issued by the foreground application preferentially, and improves the efficiency of the bottom layer equipment responding to the IO request of the foreground application to a certain extent. However, due to the time consuming effects of ancillary operations, such as encryption, decryption, compression, decompression, data verification, etc., that are attendant to the different types of read and write operations, the response time of high priority IO requests may still be higher than low priority IO requests.

As shown in fig. 1, the file system includes: virtual File System (Virtual File Systems, VFS), fourth generation extended File System (Fourth extended File System, ext 4), flash-friendly File System (Flash-Friendly File System, F2 FS), and extensible Read-Only File System (erffs), and the like.

When performing operations for writing (or writing out) data, different types of file systems may perform auxiliary operations on the written (or written out) data at the same time to promote the quasi-certainty and security of the writing (or writing out) operation. Such as encryption, decryption, compression, decompression, data verification, etc., as described above.

For example, when writing (or writing out) data to the memory through the F2FS, the electronic device 100 needs to perform an encryption (or decryption) operation on the written (or written out) data. At this time, the auxiliary operations of encryption, decryption, etc. increase the time taken for the electronic device 100 to process the IO request. Thus, when a high priority IO request involves multiple auxiliary operations such as encryption, decryption, compression, etc., the response time of the high priority IO request may be longer than the response time of a low priority IO request.

Thus, for high priority IO requests, its average response time may be higher than for low priority IO requests. That is, the simple priority-based IO request scheduling method cannot ensure that the high priority IO request must have a low response time, which results in user experience.

In order to further ensure that a foreground application obtains enough IO resources and reduce the average response time of high-priority read-write requests, the embodiment of the application provides an input-output request processing method. The method can be applied to electronic equipment such as mobile phones and tablet computers which have the capacity and need frequent read-write operations. In the description of the following embodiments, the electronic devices such as the mobile phone and the tablet computer are simply referred to as the electronic device 100.

Not limited to a cell phone, tablet computer, electronic device 100 may also be a desktop computer, a laptop computer, a handheld computer, a notebook computer, an ultra-mobile personal computer (UMPC), a netbook, a cellular telephone, a personal digital assistant (personal digital assistant, PDA), an augmented reality (augmented reality, AR) device, a Virtual Reality (VR) device, an artificial intelligence (artificial intelligence, AI) device, a wearable device, a vehicle-mounted device, a smart home device, and/or a smart city device, and the specific type of the electronic device is not particularly limited by the embodiments of the present application.

By implementing the input/output request processing method provided by the embodiment of the application, the electronic device 100 can detect the average response time of IO requests with different priorities in real time. When the average response time of the IO requests with high priority is higher than that of the IO requests with low priority, the electronic device 100 may increase the IO allocation rate of the high priority group and decrease the IO allocation rate of the low priority group.

In this way, in the same time, the electronic device 100 may process more IO requests with high priority, so as to reduce the number of waiting IO requests with high priority, ensure that the average response time of the IO requests with higher priority is lower than that of the IO requests with low priority, provide more IO resources for the foreground application, avoid blocking, and improve the user experience.

First, fig. 2 exemplarily shows a hardware configuration diagram of the electronic device 100.

The electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (universal serial bus, USB) interface 130, a charge 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, keys 190, a motor 191, an indicator 192, a camera 193, a display 194, and a subscriber identity module (subscriber identification module, SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyro sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, and the like.

The processor 110 may include one or more processing units, such as: the processor 110 may include an application processor (application processor, AP), a modem processor, a graphics processor (graphics processing unit, GPU), an image signal processor (image signal processor, ISP), a controller, a video codec, a digital signal processor (digital signal processor, DSP), a baseband processor, and/or a neural network processor (neural-network processing unit, NPU), etc. Wherein the different processing units may be separate devices or may be integrated in one or more processors.

The controller can generate operation control signals according to the instruction operation codes and the time sequence signals to finish the control of instruction fetching and instruction execution.

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. The memory may hold instructions or data that the processor 110 has just used or recycled. If the processor 110 needs to reuse the instruction or data, it can be called directly from the memory. Repeated accesses are avoided and the latency of the processor 110 is reduced, thereby improving the efficiency of the system.

In some embodiments, the processor 110 may include one or more interfaces. The interfaces may include an integrated circuit (inter-integrated circuit, I2C) interface, an integrated circuit built-in audio (inter-integrated circuit sound, I2S) interface, a pulse code modulation (pulse code modulation, PCM) interface, a universal asynchronous receiver transmitter (universal asynchronous receiver/transmitter, UART) interface, a mobile industry processor interface (mobile industry processor interface, MIPI), a general-purpose input/output (GPIO) interface, a subscriber identity module (subscriber identity module, SIM) interface, and/or a universal serial bus (universal serial bus, USB) interface, among others.

The I2C interface is a bi-directional synchronous serial bus comprising a serial data line (SDA) and a serial clock line (derail clock line, SCL). In some embodiments, the processor 110 may contain multiple sets of I2C buses. The processor 110 may be coupled to the touch sensor 180K, charger, flash, camera 193, etc., respectively, through different I2C bus interfaces. For example: the processor 110 may be coupled to the touch sensor 180K through an I2C interface, such that the processor 110 communicates with the touch sensor 180K through an I2C bus interface to implement a touch function of the electronic device 100.

The I2S interface may be used for audio communication. In some embodiments, the processor 110 may contain multiple sets of I2S buses. The processor 110 may be coupled to the audio module 170 via an I2S bus to enable communication between the processor 110 and the audio module 170. In some embodiments, the audio module 170 may transmit an audio signal to the wireless communication module 160 through the I2S interface, to implement a function of answering a call through the bluetooth headset.

PCM interfaces may also be used for audio communication to sample, quantize and encode analog signals. In some embodiments, the audio module 170 and the wireless communication module 160 may be coupled through a PCM bus interface. In some embodiments, the audio module 170 may also transmit audio signals to the wireless communication module 160 through the PCM interface to implement a function of answering a call through the bluetooth headset. Both the I2S interface and the PCM interface may be used for audio communication.

The UART interface is a universal serial data bus for asynchronous communications. The bus may be a bi-directional communication bus. It converts the data to be transmitted between serial communication and parallel communication. In some embodiments, a UART interface is typically used to connect the processor 110 with the wireless communication module 160. For example: the processor 110 communicates with a bluetooth module in the wireless communication module 160 through a UART interface to implement a bluetooth function. In some embodiments, the audio module 170 may transmit an audio signal to the wireless communication module 160 through a UART interface, to implement a function of playing music through a bluetooth headset.

The MIPI interface may be used to connect the processor 110 to peripheral devices such as a display 194, a camera 193, and the like. The MIPI interfaces include camera serial interfaces (camera serial interface, CSI), display serial interfaces (display serial interface, DSI), and the like. In some embodiments, processor 110 and camera 193 communicate through a CSI interface to implement the photographing functions of electronic device 100. The processor 110 and the display 194 communicate via a DSI interface to implement the display functionality of the electronic device 100.

The GPIO interface may be configured by software. The GPIO interface may be configured as a control signal or as a data signal. In some embodiments, a GPIO interface may be used to connect the processor 110 with the camera 193, the display 194, the wireless communication module 160, the audio module 170, the sensor module 180, and the like. The GPIO interface may also be configured as an I2C interface, an I2S interface, a UART interface, an MIPI interface, etc.

The USB interface 130 is an interface conforming to the USB standard specification, and may specifically be a Mini USB interface, a Micro USB interface, a USB Type C interface, or the like. The USB interface 130 may be used to connect a charger to charge the electronic device 100, and may also be used to transfer data between the electronic device 100 and a peripheral device. And can also be used for connecting with a headset, and playing audio through the headset. The interface may also be used to connect other electronic devices, such as AR devices, etc.

It should be understood that the interfacing relationship between the modules illustrated in the embodiments of the present application is only illustrative, and is not meant to limit the structure of the electronic device 100. In other embodiments of the present application, the electronic device 100 may also employ different interfacing manners in the above embodiments, or a combination of multiple interfacing manners.

The charge management module 140 is configured to receive a charge input from a charger. The charger can be a wireless charger or a wired charger. In some wired charging embodiments, the charge management module 140 may receive a charging input of a wired charger through the USB interface 130. In some wireless charging embodiments, the charge management module 140 may receive wireless charging input through a wireless charging coil of the electronic device 100. The charging management module 140 may also supply power to the electronic device through the power management module 141 while charging the battery 142.

The power management module 141 is used for connecting the battery 142, and the charge management module 140 and the processor 110. The power management module 141 receives input from the battery 142 and/or the charge management module 140 to power the processor 110, the internal memory 121, the display 194, the camera 193, the wireless communication module 160, and the like. The power management module 141 may also be configured to monitor battery capacity, battery cycle number, battery health (leakage, impedance) and other parameters. In other embodiments, the power management module 141 may also be provided in the processor 110. In other embodiments, the power management module 141 and the charge management module 140 may be disposed in the same device.

The wireless communication function of the electronic device 100 may be implemented by the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, a modem processor, a baseband processor, and the like.

The antennas 1 and 2 are used for transmitting and receiving electromagnetic wave signals. Each antenna in the electronic device 100 may be used to cover a single or multiple communication bands. Different antennas may also be multiplexed to improve the utilization of the antennas. For example: the antenna 1 may be multiplexed into a diversity antenna of a wireless local area network. In other embodiments, the antenna may be used in conjunction with a tuning switch.

The mobile communication module 150 may provide a solution for wireless communication including 2G/3G/4G/5G, etc., applied to the electronic device 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (low noise amplifier, LNA), etc. The mobile communication module 150 may receive electromagnetic waves from the antenna 1, perform processes such as filtering, amplifying, and the like on the received electromagnetic waves, and transmit the processed electromagnetic waves to the modem processor for demodulation. The mobile communication module 150 can amplify the signal modulated by the modem processor, and convert the signal into electromagnetic waves through the antenna 1 to radiate. In some embodiments, at least some of the functional modules of the mobile communication module 150 may be disposed in the processor 110. In some embodiments, at least some of the functional modules of the mobile communication module 150 may be provided in the same device as at least some of the modules of the processor 110.

The modem processor may include a modulator and a demodulator. The modulator is used for modulating the low-frequency baseband signal to be transmitted into a medium-high frequency signal. The demodulator is used for demodulating the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low frequency baseband signal to the baseband processor for processing. The low frequency baseband signal is processed by the baseband processor and then transferred to the application processor. The application processor outputs sound signals through an audio device (not limited to the speaker 170A, the receiver 170B, etc.), or displays images or video through the display screen 194. In some embodiments, the modem processor may be a stand-alone device. In other embodiments, the modem processor may be provided in the same device as the mobile communication module 150 or other functional module, independent of the processor 110.

The wireless communication module 160 may provide solutions for wireless communication including wireless local area network (wireless local area networks, WLAN) (e.g., wireless fidelity (wireless fidelity, wi-Fi) network), bluetooth (BT), global navigation satellite system (global navigation satellite system, GNSS), frequency modulation (frequency modulation, FM), near field wireless communication technology (near field communication, NFC), infrared technology (IR), etc., as applied to the electronic device 100. The wireless communication module 160 may be one or more devices that integrate at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via the antenna 2, modulates the electromagnetic wave signals, filters the electromagnetic wave signals, and transmits the processed signals to the processor 110. The wireless communication module 160 may also receive a signal to be transmitted from the processor 110, frequency modulate it, amplify it, and convert it to electromagnetic waves for radiation via the antenna 2.

In some embodiments, antenna 1 and mobile communication module 150 of electronic device 100 are coupled, and antenna 2 and wireless communication module 160 are coupled, such that electronic device 100 may communicate with a network and other devices through wireless communication techniques. The wireless communication techniques may include the Global System for Mobile communications (global system for mobile communications, GSM), general packet radio service (general packet radio service, GPRS), code division multiple access (code division multiple access, CDMA), wideband code division multiple access (wideband code division multiple access, WCDMA), time division code division multiple access (time-division code division multiple access, TD-SCDMA), long term evolution (long term evolution, LTE), BT, GNSS, WLAN, NFC, FM, and/or IR techniques, among others. The GNSS may include a global satellite positioning system (global positioning system, GPS), a global navigation satellite system (global navigation satellite system, GLONASS), a beidou satellite navigation system (beidou navigation satellite system, BDS), a quasi zenith satellite system (quasi-zenith satellite system, QZSS) and/or a satellite based augmentation system (satellite based augmentation systems, SBAS).

The electronic device 100 implements display functions through a GPU, a display screen 194, an application processor, and the like. The GPU is a microprocessor for image processing, and is connected to the display 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. Processor 110 may include one or more GPUs that execute program instructions to generate or change display information.

The display screen 194 is used to display images, videos, and the like. The display 194 includes a display panel. The display panel may employ a liquid crystal display (liquid crystal display, LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED) or an active-matrix organic light-emitting diode (matrix organic light emitting diode), a flexible light-emitting diode (flex), a mini, a Micro led, a Micro-OLED, a quantum dot light-emitting diode (quantum dot light emitting diodes, QLED), or the like. In some embodiments, the electronic device 100 may include 1 or N display screens 194, N being a positive integer greater than 1.

The electronic device 100 may implement photographing functions through an ISP, a camera 193, a video codec, a GPU, a display screen 194, an application processor, and the like.

The ISP is used to process data fed back by the camera 193. For example, when photographing, the shutter is opened, light is transmitted to the camera photosensitive element through the lens, the optical signal is converted into an electric signal, and the camera photosensitive element transmits the electric signal to the ISP for processing and is converted into an image visible to naked eyes. ISP can also optimize the noise, brightness and skin color of the image. The ISP can also optimize parameters such as exposure, color temperature and the like of a shooting scene. In some embodiments, the ISP may be provided in the camera 193.

The camera 193 is used to capture still images or video. The object generates an optical image through the lens and projects the optical image onto the photosensitive element. The photosensitive element may be a charge coupled device (charge coupled device, CCD) or a Complementary Metal Oxide Semiconductor (CMOS) phototransistor. The photosensitive element converts the optical signal into an electrical signal, which is then transferred to the ISP to be converted into a digital image signal. The ISP outputs the digital image signal to the DSP for processing. The DSP converts the digital image signal into an image signal in a standard RGB, YUV, or the like format. In some embodiments, electronic device 100 may include 1 or N cameras 193, N being a positive integer greater than 1.

The digital signal processor is used for processing digital signals, and can process other digital signals besides digital image signals. For example, when the electronic device 100 selects a frequency bin, the digital signal processor is used to fourier transform the frequency bin energy, or the like.

Video codecs are used to compress or decompress digital video. The electronic device 100 may support one or more video codecs. In this way, the electronic device 100 may play or record video in a variety of encoding formats, such as: dynamic picture experts group (moving picture experts group, MPEG) 1, MPEG2, MPEG3, MPEG4, etc.

The NPU is a neural-network (NN) computing processor, and can rapidly process input information by referencing a biological neural network structure, for example, referencing a transmission mode between human brain neurons, and can also continuously perform self-learning. Applications such as intelligent awareness of the electronic device 100 may be implemented through the NPU, for example: image recognition, face recognition, speech recognition, text understanding, etc.

The internal memory 121 may include one or more random access memories (random access memory, RAM) and one or more non-volatile memories (NVM).

The random access memory may include static random-access memory (SRAM), dynamic random-access memory (dynamic random access memory, DRAM), synchronous dynamic random-access memory (synchronous dynamic random access memory, SDRAM), double data rate synchronous dynamic random-access memory (double data rate synchronous dynamic random access memory, DDR SDRAM, e.g., fifth generation DDR SDRAM is commonly referred to as DDR5 SDRAM), etc. The nonvolatile memory may include a disk storage device, a flash memory (flash memory).

The FLASH memory may include NOR FLASH, NAND FLASH, 3D NAND FLASH, etc. divided according to an operation principle, may include single-level memory cells (SLC), multi-level memory cells (MLC), triple-level memory cells (TLC), quad-level memory cells (QLC), etc. divided according to a storage specification, may include universal FLASH memory (english: universal FLASH storage, UFS), embedded multimedia memory cards (embedded multi media Card, eMMC), etc. divided according to a storage specification.

The random access memory may be read directly from and written to by the processor 110, may be used to store executable programs (e.g., machine instructions) for an operating system or other on-the-fly programs, may also be used to store data for users and applications, and the like.

The nonvolatile memory may store executable programs, store data of users and applications, and the like, and may be loaded into the random access memory in advance for the processor 110 to directly read and write.

The external memory interface 120 may be used to connect external non-volatile memory to enable expansion of the memory capabilities of the electronic device 100. The external nonvolatile memory communicates with the processor 110 through the external memory interface 120 to implement a data storage function. For example, files such as music and video are stored in an external nonvolatile memory.

In the embodiment of the application, the storage device for responding to the IO request issued by the application layer and executing the input and output operation matched with the IO request comprises: an internal memory 121 and an external memory connected to the external memory interface 122.

The electronic device 100 may implement audio functions through an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, an application processor, and the like. Such as music playing, recording, etc.

The audio module 170 is used to convert digital audio information into an analog audio signal output and also to convert an analog audio input into a digital audio signal. The audio module 170 may also be used to encode and decode audio signals. In some embodiments, the audio module 170 may be disposed in the processor 110, or a portion of the functional modules of the audio module 170 may be disposed in the processor 110.

The speaker 170A, also referred to as a "horn," is used to convert audio electrical signals into sound signals. The electronic device 100 may listen to music, or to hands-free conversations, through the speaker 170A.

A receiver 170B, also referred to as a "earpiece", is used to convert the audio electrical signal into a sound signal. When electronic device 100 is answering a telephone call or voice message, voice may be received by placing receiver 170B in close proximity to the human ear.

Microphone 170C, also referred to as a "microphone" or "microphone", is used to convert sound signals into electrical signals. When making a call or transmitting voice information, the user can sound near the microphone 170C through the mouth, inputting a sound signal to the microphone 170C. The electronic device 100 may be provided with at least one microphone 170C. In other embodiments, the electronic device 100 may be provided with two microphones 170C, and may implement a noise reduction function in addition to collecting sound signals. In other embodiments, the electronic device 100 may also be provided with three, four, or more microphones 170C to enable collection of sound signals, noise reduction, identification of sound sources, directional recording functions, etc.

The earphone interface 170D is used to connect a wired earphone. The earphone interface 170D may be a USB interface 130 or a 3.5mm open mobile electronic device platform (open mobile terminal platform, OMTP) standard interface.

The electronic device 100 may further include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light sensor 180G, an ambient light sensor 180L, a fingerprint sensor 180H, a temperature sensor 180J, a bone conduction sensor 180M.

The touch sensor 180K, also referred to as a "touch device". The touch sensor 180K may be disposed on the display screen 194, and the touch sensor 180K and the display screen 194 form a touch screen, which is also called a "touch screen". The touch sensor 180K is for detecting a touch operation acting thereon or thereabout. The touch sensor may communicate the detected touch operation to the application processor to determine the touch event type. Visual output related to touch operations may be provided through the display 194. In other embodiments, the touch sensor 180K may also be disposed on the surface of the electronic device 100 at a different location than the display 194.

In an embodiment of the present application, the electronic device 100 detects an operation on the mobile phone screen, for example, an operation of clicking a certain application icon to run the application (refer to the user interface shown in fig. 5A), which may be performed by the touch sensor 180K.

The keys 190 include a power-on key, a volume key, etc. The keys 190 may be mechanical keys. Or may be a touch key. The electronic device 100 may receive key inputs, generating key signal inputs related to user settings and function controls of the electronic device 100.

The motor 191 may generate a vibration cue. The motor 191 may be used for incoming call vibration alerting as well as for touch vibration feedback. For example, touch operations acting on different applications (e.g., photographing, audio playing, etc.) may correspond to different vibration feedback effects. The motor 191 may also correspond to different vibration feedback effects by touching different areas of the display screen 194. Different application scenarios (such as time reminding, receiving information, alarm clock, game, etc.) can also correspond to different vibration feedback effects. The touch vibration feedback effect may also support customization.

The indicator 192 may be an indicator light, may be used to indicate a state of charge, a change in charge, a message indicating a missed call, a notification, etc.

The SIM card interface 195 is used to connect a SIM card. The SIM card may be inserted into the SIM card interface 195, or removed from the SIM card interface 195 to enable contact and separation with the electronic device 100. The electronic device 100 may support 1 or N SIM card interfaces, N being a positive integer greater than 1. The SIM card interface 195 may support Nano SIM cards, micro SIM cards, and the like. The same SIM card interface 195 may be used to insert multiple cards simultaneously. The types of the plurality of cards may be the same or different. The SIM card interface 195 may also be compatible with different types of SIM cards. The SIM card interface 195 may also be compatible with external memory cards. The electronic device 100 interacts with the network through the SIM card to realize functions such as communication and data communication. In some embodiments, the electronic device 100 employs esims, i.e.: an embedded SIM card. The eSIM card can be embedded in the electronic device 100 and cannot be separated from the electronic device 100.

It should be understood that the illustrated structure of the embodiment of the present application does not constitute a specific limitation on the electronic device 100. In other embodiments of the application, electronic device 100 may include more or fewer components than shown in FIG. 2, or certain components may be combined, certain components may be separated, or a different arrangement of components may be provided. The components shown in fig. 2 may be implemented in hardware, software, or a combination of software and hardware.

The following specifically describes a method for processing an input/output request provided by an embodiment of the present application.

Based on the software architecture of the electronic device 100 shown in fig. 1, the embodiment of the present application provides a schematic diagram of the software architecture of the improved electronic device 100 shown in fig. 3A. The following is a detailed description in conjunction with fig. 3A: in the process of implementing the input/output request processing method provided by the embodiment of the application, the workflow of software and hardware of the electronic device 100.

As shown in fig. 3A, the software architecture of the electronic device 100 can also be divided into 3 layers: an application layer, a kernel layer, and a device layer.

The application layer may include one or more application programs and a latency detection module 211. The one or more applications are, for example, application 1 (APP 1), application 2 (APP 2). The application may be a system-provided application or a third party application.

During the running of an application, the application may initiate one or more processes. For example, in running a video and audio application to play video, the application maintenance process may include: a user operation monitoring process, a video data acquisition process, an image data rendering process, an audio processing process, and the like. For any process, the process may in turn initiate one or more IO requests. Thus, the electronic device 100 may detect multiple IO requests initiated by one or more applications simultaneously.

The delay detection module 211 may be configured to detect average response times of IO requests of different priorities. Specifically, when it is detected that a process initiates an IO request, the delay detection module 211 may obtain a timestamp (initiation time) of the process initiating the IO request. After the input/output operation indicated by the IO request is performed, the storage device 217 may return the processing result to the application layer. The processing result may include a time stamp (response time) when the storage device 217 executed the IO request described above. At this time, the delay detection module 211 may obtain the response time from the processing result.

The time consumed between the initiation time and the response time is the response time of the electronic device to process the IO request. The delay detection module 211 may perform packet statistics on response times of numerous IO requests issued by the application layer according to the type of the priority, so as to calculate average response times of IO requests with the same priority.

The kernel layer includes a File System 212 (File System) and blocks (blocks).

The file system 212 reflects the method and form of organizing files on a storage device. Different file systems 212 organize and manage files differently. The IO request may go through the file system 212 before the storage device of the electronic device 100 executes the IO request issued by the application layer. The file system 212 processes the IO request according to its preset organization and management file, so that the IO request becomes data that can be operated in the target storage space of the IO request.

For example, when the file system 212 is F2FS, after receiving a certain IO request (input request or output request) issued by the application layer, the F2FS may perform an encryption operation on the IO request, so that data corresponding to the IO request can be written (or written out) to the storage device more securely.

Referring to the description of FIG. 1, file system 212 is of numerous types. Due to the different methods of processing the IO requests by different file systems 212, the back-end delays of the IO requests passing through different file systems 212 are different. The back-end latency refers to the time consumed by the file system 212 to make the IO request into data operable in the target storage space of the IO request according to the method of organizing and managing files preset by itself. Backend latency is an important factor affecting the response time of IO requests.

The Block (Block) includes a packet quota module 213, a return control module 214, and a read-write scheduling module 215.

The packet quota module 213 may dynamically adjust occupancy ratios of IO requests of different priorities to IO resources according to average response times of IO requests of different priorities, i.e. dynamically adjust scheduling ratios of IO resources. The return control module 214 may be used to control the return rate of IO processing results. Here, the return rate refers to the rate at which the IO processing result is returned from the kernel layer Block to the application program that initiated the IO request. The read-write scheduling module 215 may determine the number and the sequence (i.e. the processing priority) of the processing IO requests with different priorities of the electronic device 100 according to the scheduling policy preset by the packet quota module 213.

The following embodiments will describe the working principles of the packet quota module 213, the return control module 214, and the read/write scheduling module 215 in detail, and will not be expanded here.

The device layer includes a storage device 217. The storage device includes a volatile storage device and a nonvolatile storage device. The non-volatile storage device may be an SSD, an MMC/eMMC, or the like, and specifically, reference may be made to the description of fig. 1, which is not repeated here. The memory device 217 may be controlled to perform input and output operations indicated by the IO request.

The process of the electronic device 100 processing the IO request issued by the application program on the basis of the software architecture diagram shown in fig. 3A may refer to fig. 3B.

As shown in fig. 3B, APP1 may be a foreground application (application directly operated by the user); APP2 may be a background application (application program that is not directly operated by the user).

Generally, since the foreground application needs to feed back to the user in time, the delay tolerance of the IO request initiated by the foreground application is low (i.e. the delay requirement is high). The delay tolerance refers to the degree of delay in receiving the response. After detecting an IO request initiated by a foreground application, the electronic device 100 needs to process the IO request in as short a time as possible. And the background application does not need immediate feedback to the user, so the background application has higher delay tolerance (lower immediate delay requirement). Upon detecting an IO request initiated by a background application, electronic device 100 may less urgently process the IO request.

Thus, after simultaneously detecting an IO request with a higher latency requirement and an IO request with a lower latency requirement, the electronic device 100 may preferentially process the IO request with a higher latency requirement.

For example, APP1 may initiate an IO request (IO 1); APP2 may initiate two IO requests (IO 2, IO 3). The delay requirement for IO1 is, for example, 5ms, the delay requirement for IO2 is, for example, 10ms, and the delay requirement for IO3 is, for example, 15ms. Thus, IO1 may be a high priority IO request and IO2, IO3 may be a low priority IO request. Wherein, the priority of IO2 may be higher than IO3. I.e. priority IO1 is higher than IO2 than IO3. Here, we denote the processing priorities of the electronic device 100 to process the above 3 IO requests by priorities A, B, C (a > B > C), respectively. Wherein, the priority of IO1 is A; the priority of IO2 is B; the priority of IO3 is C. It will be appreciated that the above-mentioned correspondence between latency requirements and IO processing priorities is merely exemplary, and should not be construed as limiting the embodiments of the present application.

In a scenario where the electronic device 100 runs a video application and a gallery application simultaneously: the video application in the background running state may initiate a write request to write the downloaded video data (IO 3) to the storage device 217; IO2 may be IO requests initiated by some system applications or processes; the gallery application in foreground running state may initiate a read request to read a certain picture (IO 1) from the storage device 217. It will be appreciated that the latency requirements of different processes of the same application may also be different, and therefore, the 3 IO requests may also be initiated by the same application.

Taking IO1 as an example, after the APP1 initiates IO1, the delay detection module 211 may detect the arrival of IO1, and at this time, the delay detection module 211 may record the current time as the initiation time of IO 1. Similarly, the delay detection module 211 may record the time when the APP2 initiates the IO2 and the IO3, i.e. the respective initiation times of the IO2 and the IO 3.

IO requests issued by the application layer pass through the file system and can reach blocks (blocks). The delay of this one down-going process can be noted as Δt1. With reference to fig. 1, the file organization forms used by the target storage spaces of different IO requests are different, that is, the file systems through which the IO requests pass are different, and the Δt1 values of the different IO requests are different. This is also an important factor in causing the overall latency of a high priority to be potentially longer than the overall latency of a low priority.

After the IO request reaches the Block, the read-write scheduling module 215 may determine, according to the priority to which the IO request belongs, the order in which the underlying storage device 217 processes the IO request. The time that the IO request waits to be processed at the read/write scheduling module 215 may be denoted as Deltat 2. In the embodiment of the present application, the read-write scheduling module 215 also depends on the packet quota module 213 in determining the sequence in which the storage device 217 processes the IO requests.

Specifically, the working principles of the packet quota module 213 and the read/write schedule module 215 are as follows:

the packet quota module 213 may record a ratio of the number of IO requests of different priorities processed by the electronic device 100 in one period, abbreviated as a scheduling ratio. The read-write scheduling module 215 may obtain a specific number of IO requests from the buffer area that receives the IO requests issued by the application layer according to the scheduling ratio recorded in the packet quota module 213, and determine an order in which the specific number of IO requests are issued to the storage device 217.

Fig. 4A illustrates a procedure in which the read-write scheduling module 215 processes a received IO request according to the schedule proportioning recorded in the packet quota module 213.

Corresponding to the priority A, B, C, the buffer area for receiving the IO request issued by the application layer may include 3 buffer queues, which are a queue, B queue and C queue respectively. The 3 queues are used for caching IO requests with different priorities of the 3 classes. Wherein, the A queue can be used for caching IO requests with priority A (A-class IO requests); the B queue can be used for caching IO requests with priority B (B-class IO requests); the C queue may be used to cache IO requests with priority C (class C IO requests).

After detecting the IO request issued by the application layer, the electronic device 100 may identify the priority of the IO request, and then, the electronic device 100 may cache the IO request into a queue corresponding to the priority, and wait for the response of the underlying storage device.

In combination with IO1 (a), IO2 (B), and IO3 (C) shown in fig. 3B, when IO1 is detected, the electronic device 100 may insert IO1 into the a queue; when IO2 is detected, the electronic device 100 may insert IO2 into the B queue; when IO3 is detected, the electronic device 100 may insert IO3 into the C queue.

It will be appreciated that the priority type of IO requests in electronic device 100 may also be other, i.e., include more or less priority levels, according to different partitioning principles, or by merging or splitting the 3 types of priorities. Accordingly, the electronic device 100 may tag IO requests initiated by different applications or processes according to the new priority classification. The embodiments of the present application are not limited in this regard. In other embodiments, IO requests of different priorities may also be cached in one storage area.

The electronic device 100 may also include a dispatch queue Q. The dispatch queue Q is also used to cache IO requests. IO requests dequeued from the A, B, and C queues may be cached to the dispatch queue Q. The order in which IO requests are queued in dispatch queue Q may indicate the order in which storage device 217 actually processed the IO requests.

After IO1, IO2, IO3 reach the buffer queue, IO1, IO2, IO3 may wait in the buffer queue. At this time, the read/write scheduling module 215 may obtain the current scheduling ratio from the packet quota module 213. Then, the electronic device 100 may sequentially invoke a corresponding number of class a IO requests, class B IO requests, and class C IO requests from the class a queue, the class B queue, and the class C queue according to the scheduling ratio recorded in the packet quota module 213, and sequentially insert the IO requests into the scheduling queue Q. In the case where IO requests of different priorities are cached in one storage area, the read/write scheduling module 215 may identify the IO request according to the priority identifier of each IO request, and determine whether to store it in the scheduling queue Q.

In general, the electronic device 100 needs to preferentially process IO requests with high priority. Thus, in most cases, the electronic device 100 needs to allocate more IO resources for high priority IO requests. Therefore, generally, in the preset scheduling proportion, the numerical value of the ratio item indicating the class a IO request is larger. In this way, electronic device 100 may allocate more IO resources to high priority class A IO requests to quickly respond to a user's request.

For example, assume that the schedule ratio recorded in the packet quota module 213 is 5:3:2. At this time, in a period, according to the scheduling ratio, the read/write scheduling module 215 may respectively obtain 5 class a IO requests, 3 class B IO requests, and 2 class C IO requests from the cache queue A, B, C, and sequentially insert the IO requests into the scheduling queue Q. The 5 class a IO requests, the 3 class B IO requests, and the 2 class C IO requests include IO1, IO2, and IO3 waiting in the buffer queue A, B, C, respectively. In other embodiments, according to the schedule ratio of 5:3:2, the read/write schedule module 215 may also obtain 10 class a IO requests, 6 class B IO requests, 4 class C IO requests (10:6:4=5:3:2), and so on from the above-mentioned cache region.

The read/write scheduling module 215 may then issue the various IO requests to the storage device 217 sequentially in the order of the IO requests in the scheduling queue Q. In response to the IO request described above, the storage device 217 may perform input-output operations indicated by the IO request.

Returning to FIG. 3B, after storage device 217 processes the IO request, storage device 217 may return the processing results of the IO request to the application that originated the IO request. The time taken for storage device 217 to process an IO request may be denoted as Deltat 3. The time taken for the storage device 217 to return processing IO requests to the application receiving the IO processing results described above may be denoted as Deltat 4. The main factor affecting Δt3 is the type of storage device, so in the embodiment of the present application, the time for the storage device 217 to perform the input/output operation in response to different IO requests may be considered the same, i.e. Δt3 of different IO requests may be considered the same.

For example, after the storage device 217 sequentially performs the input/output operations indicated by IO1, IO2, and IO3, the storage device 217 may return the processing results (IO processing results) of IO1, IO2, and IO3 to the application layer. The processing results include acknowledgement characters (e.g., ACKs), and/or input or output data.

The IO processing results may pass through a return control module 214 before being passed back to the application layer. Fig. 4B illustrates the operation of the return control module 214.

As shown in fig. 4B, the return control module 214 may detect the IO processing result returned by the storage device 217. First, the return control module 214 may identify the priority of the processing result, and further, the return control module 214 may control the return rate of the processing result of the low-priority IO request according to the current return control policy.

In connection with the plurality of IO requests in the scheduling queue Q shown in fig. 4A, as shown in fig. 4B, the return control module 214 may sequentially receive the processing results of the above-mentioned IO requests (5 class a IO requests, 3 class B IO requests, and 2 class C IO requests) returned by the storage device 217. Here, the rectangular block labeled "IO" in fig. 4B is different from the ideas of fig. 4A, in which one rectangular block labeled "IO" in fig. 4A represents one IO request, and one rectangular block labeled "IO" in fig. 4B represents the processing result generated after the storage device 217 processes one IO request.

For any one of the above IO requests, after receiving the processing result of the IO request, the return control module 214 may determine, according to the identifier of the IO request in the processing result, the IO request described by the processing result and the priority of the IO request.

In the scenario of limiting the return rate of the low priority IO processing result, if the processing result is the low priority IO processing result, the return control module 214 may delay sending the processing result to the file system 212 and the application layer.

For example, in a scenario in which the return rate of the IO processing result of the class C priority is limited, when the received IO processing result is the processing result of the IO request of the class a priority (or the processing result of the IO request of the class B priority), the return control module 214 may normally transfer the IO processing result back to the application layer. When the received IO processing result is the processing result of the IO request with the class C priority, the return control module 214 may retain the IO processing result in the return control module 214 for a period of time later, and then return the IO processing result to the application layer. The period of time is preset, for example, 0.1ms or the like.

For any IO request, if the IO processing result is limited by the return control module 214 when the IO processing result is returned to the application layer, the time Δt4 for returning to the application layer is prolonged. In this way, as the processing result of the low-priority IO request is delayed to be received, the activity of the application program that initiates the IO request may be reduced, so as to improve the efficiency of processing the high-priority IO request by the electronic device 100.

The operation of the return control module 214 in determining the return control strategy will be described in detail first. Taking the foregoing 3-level priority classification (A, B, C) shown in fig. 4A as an example, fig. 4C shows a flowchart in which the electronic device 100 determines a return control policy according to the current load of the CPU.

S101, the electronic device 100 queries the current load H0 of the CPU.

The electronic device 100 may determine the current load of the CPU, denoted as H0, including the occupation condition of the CPU, the number of processes waiting for the CPU resources, and so on through a function provided by the system for querying the operating state of the CPU.

For example, when all processing cores of the CPU are occupied and there are a large number of processes waiting for the CPU to process, at this time, the electronic device 100 may determine that the CPU load is high (busy). The above-described functions, such as vmstat () function, mpstat () function, etc., provided by Linux, to which embodiments of the present application are not limited.

The electronic device 100 may then compare the current load to a preset load threshold, and determine whether to limit the return rate of low priority IO requests.

The electronic device 100 may be provided with a load threshold H1, and a load threshold H2. Wherein H1< H2. The load threshold set in two stages described above may reflect: the electronic device 100 limits the degree of variability in the low priority IO request return rate. Of course, the electronic device 100 may also set more or fewer load thresholds. The embodiments of the present application are not limited in this regard.

After acquiring the current load of the CPU, the electronic device 100 may compare the current load with the load thresholds (H1, H2). First, S102: the electronic device 100 may compare the current load with the threshold H2, and determine whether the current load of the CPU is higher than the threshold H2.

If the current load is higher than H2, i.e., H2< H0, the CPU of the electronic device 100 is very busy. At this time, S103: the electronic device 100 may limit the return rate of all low priority IO requests (e.g., limit the return rate of IO requests with priorities B and C). The electronic device 100, embodied on an application, may limit the return rate of IO requests initiated by non-foreground-like applications, including system applications and background applications.

If the current load is lower than H2, H0< H2, then S104: the electronic device 100 may continue to compare the current load with the threshold H1 to determine whether the current load of the CPU is higher than the threshold H1.

If the current load is higher than H1, i.e., H1< H0< H2, the CPU of the electronic device 100 is busy. At this time, S105: the electronic device 100 may limit the return rate of a portion of the low priority IO requests (e.g., limit the return rate of only IO requests with priority C). The electronic device 100 may be embodied on an application program that limits only the return rate of IO requests initiated by a background class application program, and not the return rate of IO requests initiated by a system class application program.

If the current load is lower than H1, i.e., H0< H1, the CPU of the electronic device 100 may be considered idle. At this time, S106: the electronic device 100 may not limit the return rate of any IO requests.

Thus, when the processor of the electronic device 100 is busy but the IO resource is idle, the electronic device 100 may reduce the CPU resource occupation of the background application by controlling the return rate of the low-priority IO request, thereby improving the processing performance of the foreground application. Meanwhile, the background application is limited from the return end, so that the utilization rate of IO resources can be improved.

Returning to fig. 3B, after passing through the return control module 214, the IO processing result may return to the application program that initiated the IO request through the file system 212 and the delay detection module 211. For example, IO1 may return APP1, IO2, IO3 may return APP2.

When the IO processing result passes through the delay detection module 211, the delay detection module 211 may determine that the current time is the time (end time) when the electronic device 100 finishes processing the IO request corresponding to the IO processing result. Also taking IO1 as an example, after the processing result of IO1 reaches the delay detection module 211, the delay detection module 211 may determine that the current time is the time when the electronic device 100 finishes processing IO 1. In connection with the foregoing description, after the APP1 initiates the IO1, the time (initiation time) of the IO1 is detected by the delay detection module 211, and through the two times (initiation time and end time) of the time, the delay detection module 211 may determine the total time of the electronic device 100 for processing the IO1, i.e. the response time, which is denoted as T1.

By analogy, the delay detection module 211 may sequentially determine the time of processing each IO request by the electronic device 100 in one IO processing period, i.e. the response time of each IO request. In this way, the delay detection module 211 may determine that the response time of IO2 is T2 and the response time of IO3 is T3.

Generally, the electronic device 100 preferentially processes the class a IO requests, so the response time of the class a IO requests should be the shortest. In IO1, IO2, IO3, the response times T1, T2, T3 of IO1, IO2, IO3 should satisfy: t1< T2< T3. However, due to the time consumption on paths such as Δt1, Δt2, etc., especially the file system 212 through which different IO requests pass is different (Δt2 is different), this may result in that the response time of the IO request with high priority may be longer than that of the IO request with low priority. This is because the processing of the data addition is different for different file systems (encryption, decryption, compression, decompression, data verification, etc. operations).

For example, IO1 may have a Δt1 greater than Δt1 of IO2 due to encryption and compression operations, and thus IO1 may have a longer response time than IO 1.

For example, t1= Δt1 (IO 1) +Δt2 (IO 1) +Δt3 (IO 1) +Δt4 (IO 1) =10 ms;

T2＝△t1(IO2)+△t2(IO2)+△t3(IO2)+△t4(IO2)＝9ms；

T3＝△t1(IO3)+△t2(IO3)+△t3(IO3)+△t4(IO3)＝11ms；

wherein T1> T2 does not satisfy T1< T2.

At this time, the packet quota module 213 may obtain the response time of the different IO requests. Further, the packet quota module 213 may determine whether the response time of the different IO requests satisfies: the response time of the high priority IO requests is less than the response time of the low priority IO requests.

Optionally, after the delay detection module 211 determines the response time of each IO request, the delay detection module 211 may also determine the average response time of the IO requests with the same priority.

For example, storage device 217 may first process the 5 class A IO requests described above, in the order of IO requests in dispatch queue Q. After each IO request is processed, storage device 217 may generate the processing results for the IO request. The processing result may include a time stamp (response time) when the storage device 217 processed the IO request. At this time, in combination with the application program issuing other initiation times of the IO request, the delay detection module 211 may determine a total time consumed by the electronic device 100 in responding to the IO request, i.e. a response time. After the above 5 class a IO requests are executed, the delay detection module 211 may determine an average response time of the class a IO requests, denoted as AvgT1.

Likewise, referring to the above processing method, the electronic device 100 may sequentially determine average response times of the class B IO request and the class C IO request, which are denoted as AvgT2 and AvgT3. At this time, the electronic device 100 may determine average response times of the class a IO request, the class B IO request, and the class C IO request to be AvgT1, avgT2, and AvgT3, respectively.

At this time, the packet quota module 213 may obtain the average response times of the IO requests with different priorities. Further, the packet quota module 213 may determine whether the average response time satisfies: the average response time of the high priority IO requests is less than the average response time of the low priority IO requests.

Taking the average response time as an example, after determining AvgT1, avgT2, avgT3, the electronic device 100 may adjust the scheduling ratio in the packet quota module 213 according to the average response time.

Specifically, the packet quota module 213 may obtain the average response time of the IO requests of each priority from the latency detection module 211. The packet quota module 213 may then check whether the average response time of the high priority IO requests is lower than the average response time of the low priority IO requests. When the average response time of the high priority IO requests is lower than the average response time of the low priority IO requests, the packet quota module 213 may determine that: the efficiency of processing high priority IO requests currently cannot meet the demand that users wish to respond to high priority IO requests as soon as possible. At this time, the electronic device 100 needs to adjust the allocation of the IO resources, and provide more IO resources to the IO requests with high priority, that is, improve the proportion of the high priority in the scheduling proportion, so as to further meet the requirements of the foreground application, and avoid the influence of the overlong response time on the user experience.

For example, in the case where the scheduling ratio is 5:3:2, if AvgT1> AvgT2, that is, the average response time of the class a IO requests is higher than the average response time of the class B IO requests, the electronic device 100 may adjust the scheduling ratio to 6:2:2. Thus, the electronic device 100 may process 5 class a IO requests from the original 1ms, and advance to process 6 class a IO requests from 1 ms. Thus, the electronic device 100 may process more class a IO requests in the same unit time, and the average response time of the class a IO requests may be reduced.

Similarly, if AvgT2> AvgT3, the electronic device 100 may increase the IO resource occupancy ratio of the class B IO requests and decrease the IO resource occupancy ratio of the class C IO requests, for example, the electronic device 100 may adjust the scheduling ratio (5:3:2) to 5:4:1, so that the electronic device 100 may process more class B IO requests.

In this way, when the average response time of the IO request with high priority is higher than the average response time of the IO request with low priority, the electronic device 100 may determine that the IO resource currently allocated to the IO request with high priority cannot meet the requirement of the IO request with high priority. Thus, electronic device 100 may readjust the allocation of IO resources, allocating more IO resources for high priority IO requests to reduce the average response time of the high priority IO requests.

The packet quota module 213 may also adjust the scheduling ratio according to the response time of a single IO request. For example, after the packet quota module 213 obtains the response times T1, T2, and T3 of IO1, IO2, and IO3, after determining that T1> T2, the packet quota module 213 may also promote the ratio of the term of IO1 in the scheduling ratio, and the specific reference may be made to the above-mentioned average response time adjustment method, which is not described herein.

In some embodiments, the number of class a IO requests may be reduced when the foreground application is closed or the need for IO resources by the foreground application is significantly reduced. At this time, the electronic device 100 may readjust the scheduling ratio, appropriately reduce the ratio of the class a IO requests to the occupation of the IO resources, and improve the ratio of the class B IO requests to the class C IO requests.

For example, in the process that the electronic device 100 obtains each group of IO requests according to the scheduling ratio of 6:2:2, if the number of class a IO requests in the waiting state in the queue a is detected to be lower than the number indicated by the scheduling ratio for multiple times, the electronic device 100 may reduce the ratio of class a IO requests to IO resources occupation, for example, restore the scheduling ratio to 5:3:2, or further reduce the ratio of class a IO requests to IO resources occupation, for example, adjust the scheduling ratio to 4:4:2 or 4:3:3, and so on. The embodiments of the present application are not limited in this regard.

Of course, in other embodiments, when the foreground application is turned off or the requirement of the foreground application for the IO resource is significantly reduced, the electronic device 100 may also continue to use the foregoing scheduling ratio, which is not described herein.

And then the read-write scheduling module can acquire IO requests with different priorities from the buffer queue A, B, C according to the new scheduling proportion.

In other embodiments, after acquiring the data in the latency detection module 211, the packet quota module 213 may check whether the response time of each IO request meets its own latency requirement. When the response time does not meet the own delay requirement, the packet quota module 213 may also adjust the scheduling ratio of different priorities. For example, the response time of the IO1 is 10ms, and the own delay requirement is 5ms, that is, the response time of the IO1 does not meet the own delay requirement, and at this time, the packet quota module 213 may promote the ratio of the priorities of the IO1 in the scheduling ratio.

It should be understood that the illustrated structure of the embodiment of the present application does not constitute a specific limitation on the electronic device 100. In other embodiments of the application, the electronic device 100 may include more or fewer hierarchies and functional modules than shown in FIG. 3A, or may combine certain hierarchies and functional modules, or split certain hierarchies and functional modules, or may be an arrangement of different hierarchies and functional modules. The components shown in fig. 3A may be implemented in hardware, software, or a combination of software and hardware.

Fig. 5A-5B illustrate user interfaces for running applications on electronic device 100.

Fig. 5A shows the user interface of the electronic device 100 presenting an installed application. As shown in FIG. 5A, the user interface may include a status bar 411, one or more application icons 412, a commonly used application icon tray 413, a page indicator 414, and the like.

Wherein status bar 411 may include: one or more signal strength indicators of mobile communication signals (also may be referred to as cellular signals), one or more signal strength indicators of high fidelity wireless communication (wireless fidelity, wi-Fi) signals, battery status indicators, time indicators, and the like.

The one or more application icons 412 may include: setting (Setting), application market (APP store), gallery (photo), browser (Browser), etc. When detecting a user operation on any of the icons described above, the electronic device 100 may run the application indicated by the icon. For example, upon detecting a user operation, such as a click operation, of an icon acting on a gallery (photo) application, the electronic device 100 may run the gallery application.

Icons for one or more applications may be displayed in the commonly used application icon tray 413. The one or more applications are often user-specific applications set by the user, such as applications for cameras, address books, telephones, information, etc. The application icons in the common application icon tray 413 remain displayed at the time of page switching. The tray icons described above are optional, and embodiments of the present application are not limited thereto. Page indicator 414 may be used to indicate the positional relationship of the currently displayed page to other pages.

One or more application icons 412 may be distributed across multiple pages, and page indicator 414 may also be used to indicate which of the pages the user is currently browsing. The user may slide the area of the other application icons left and right to view the application icons in the other pages.

In some embodiments, the user interface shown in FIG. 5A may present a home page (home) of an application for electronic device 100. It will be appreciated that fig. 5A illustrates only one possible user interface of the electronic device 100 and should not be construed as limiting embodiments of the application.

In response to a user operation acting on an icon at any one of the applications, the electronic device 100 may run the application indicated by the icon. In running a gallery application, the application may initiate multiple IO requests. The IO request includes an IO request to acquire computer program code, system data, and user data necessary for the application program to run.

Fig. 5B shows one user interface for the electronic device 100 running a gallery application. As shown in fig. 5B, the user interface includes a search bar 421, icons 422 for one or more albums, a menu bar 423, and the like.

The search bar 421 may be used to search for pictures. For example, the user may enter the keyword "flower" in the search bar 421. The electronic device 100 may detect a user operation on the search bar 421, in response to which the electronic device 100 may find a picture whose picture content includes "flowers" among all the pictures stored in the gallery.

Icons 422 of one or more albums may represent one or more folders storing image data. As shown in fig. 5B, the album includes a camera (Cmera), screen shot (ScreenShot), download (Download), and the like. The image displayed in the album icon may be any one of the pictures in the album.

Menu bar 423 may include one or more controls, such as a photo control, an album control, a time of day control. The control can provide the function of displaying the images stored in the gallery in different arrangement modes for the user. For example, upon detecting a user operation acting on the time control, the electronic device 100 may display all images in the gallery in chronological order of the images.

During the operation of the gallery application by the electronic device 100, the gallery application may initiate a plurality of IO requests. In response to the plurality of IO requests, the gallery application may obtain computer program code, system data, and user data for the gallery application.

For example, when the gallery application needs to display the user interface shown in FIG. 5B, the gallery application may initiate an IO request to read the code of the user interface, including the code of the page layout. Upon displaying the user interface shown in FIG. 5B, the gallery application may initiate an IO request to read the control icon resources. In addition, the gallery application may initiate IO requests to read images stored in the storage device. In this way, the user interface shown in fig. 5B can display image data such as a plurality of pictures, moving pictures, videos, and the like stored on the electronic device 100.

The electronic device 100 may detect a plurality of user operations of clicking a certain application icon, and in response to the user operations, the electronic device 100 may run a plurality of applications. For the plurality of applications, some applications are applications that the user is operating, i.e., foreground applications, while other applications are applications that run in the background, i.e., background applications. At the same time, the electronic device 100 also runs some system applications, processes, or services that provide services for foreground applications and/or background applications.

In displaying the user interface shown in fig. 5B, the electronic device 100 may detect a certain user operation, and in response to the operation, the electronic device 100 may display an application program that is running. For example, as shown in fig. 5B, the electronic apparatus 100 may detect an operation by which the user slides up from the bottom of the screen. In response to the above operation, the electronic device 100 may display the user interface shown in fig. 5C.

As shown in fig. 5C, the user interface includes a page 431. Page 431 may represent a gallery application (Photos) running in response to the user operations shown in FIGS. 5A and 5B described above. In addition, the user interface includes pages 432, 433. Page 432 may represent a running Browser application (Browser); page 433 may represent a running setup application (Settings).

Not limited to the browser application and the setting application, the electronic device 100 may also run other more application programs, i.e., the user interface shown in fig. 5C may also display more pages.

The gallery application described above (the application that the user is directly operating) may be referred to as a foreground application. Other applications, such as the browser application, the setup application, and the like, that are not currently being operated directly by the user may be referred to as background applications.

The latency requirements of different IO requests may be different. In general, the delay requirement of an IO request initiated by an application program with low delay tolerance is high. The delay tolerance of the foreground application is low. Therefore, the latency requirement of the IO requests initiated by the foreground application is high, i.e. the priority of the electronic device 100 to process such IO requests is high. The electronic device 100 needs to process this type of IO request as soon as possible. Compared with the IO request initiated by the foreground application, the processing priority of the IO request initiated by the background application is lower. For example, the priority of the IO request initiated by the gallery application is higher than that of the IO request initiated by the browser application and the setting application.

In this way, after receiving a plurality of IO requests, the electronic device 100 may process the plurality of IO requests sequentially from high to low according to the processing priorities of different IO requests, so as to make the IO requests with different delay requirements all obtain the response of the electronic device 100 within the respective delay requirements as much as possible.

Fig. 6 is a flowchart schematically illustrating an input/output processing method provided by the embodiment of the present application implemented by the electronic device 100.

S201, the electronic equipment 100 processes IO requests with different priorities according to preset scheduling proportions.

After the initialization is completed, the electronic device 100 may allocate IO resources for the IO requests with different priorities according to a preset scheduling ratio, that is, determine the number of IO requests with different priorities processed by the electronic device 100 in one processing period.

Specifically, in connection with FIG. 3A, an IO request initiated by an application layer may be issued to a kernel layer Block. Typically, a Block will receive multiple IO requests simultaneously. After receiving the IO request, the electronic device 100 may determine a latency requirement of the IO request. For the IO request with higher delay requirement, namely the IO request requiring quick response, the Block can preferentially issue the IO request to a memory driver (storage driver) of the IO request target storage.

In order to avoid that the low-priority IO requests are always preempted by the high-priority IO requests, the electronic device 100 may process the IO requests with different priorities according to a preset scheduling ratio, so as to ensure that the low-priority IO requests are not blocked.

For example, as shown in fig. 4A, in a unit time, the electronic device 100 may sequentially process 5 IO requests of high priority (a), 3 IO requests of medium priority (B), 2 IO requests of low priority (C). In the unit time, after the electronic device 100 processes the IO request with the high priority, even if other IO requests with the high priority exist in the Block, the electronic device 100 will process some IO requests with the medium priority and the low priority first, so as to avoid blocking the IO requests with the medium priority and the low priority, which results in that an application program or a process that initiates the IO request is blocked.

In the case of ensuring that lower priority IO requests are not blocked, electronic device 100 may allocate as much IO resources as possible to higher priority IO requests. This is often because the application or process that initiates the high priority IO request is mostly directly related to the user operation. If higher response efficiency of the high-priority IO request is not ensured as much as possible, the user experience is greatly reduced.

S202, the electronic device 100 updates the average response time of the IO requests with different priorities in real time.

In the process of processing the IO requests with different priorities according to the preset scheduling ratio, the electronic device 100 may detect the average response time of the IO requests with different priorities in real time.

As shown in fig. 3A, the electronic device 100 may be preset with a delay detection module 211. The delay detection module 211 may calculate average response times of the IO requests with the same priority during the process of processing the IO requests with different priorities by the electronic device 100.

Specifically, after an application or process initiates an IO request, the delay detection module 211 may determine a timestamp of the application or process initiating the IO request, and mark the timestamp as an initiation time of the IO request. When the storage device of the electronic device 100 performs the input/output operation corresponding to the IO request according to the instruction of the IO request, the application layer may receive the processing result returned by the device layer. At this time, the delay detection module 211 may determine the time when the electronic device 100 finishes processing the IO request according to the processing result. For example, the delay detection module 211 may determine that the time when the application layer receives the processing result is the time when the electronic device 100 finishes processing the IO request (response time). Based on the initiation time and the response time, the delay detection module 211 may determine a response time of the electronic device 100 to process the IO request.

In conjunction with the schematic diagram shown in fig. 4A, during the execution of the 5 IO requests with priority a in the scheduling queue Q by the electronic device 100, the latency detection module 211 may determine the response time of the 5 IO requests according to the above method. The latency detection module 211 may then determine an average response time (AvgT 1) of the 5 IO requests with priority a.

Likewise, in executing IO requests of priorities B and C in the dispatch queue Q, the latency detection module 211 may sequentially determine an average response time (AvgT 2) of the IO requests of priority B and an average response time (AvgT 3) of the IO requests of priority C. Typically, avgT1< AvgT2< AvgT3.

S203, the electronic device 100 determines whether to adjust the scheduling ratio according to the average response time.

After determining the average response time of the IO requests with different priorities, the electronic device 100 may determine whether the average response time of the IO requests with high priority is higher than the average response time of the IO requests with low priority according to the average response time.

When the average response time of the high-priority IO requests is higher than the average response time of the low-priority IO requests, the electronic device 100 may determine that the IO resources currently allocated to the high-priority IO requests by the system cannot meet the requirements of the high-priority IO requests. Thus, the electronic device 100 needs to allocate more IO resources for the high-priority IO request to promote the average response time of the high-priority IO request.

In connection with the schematic shown in fig. 4A, if AvgT1> AvgT2, this illustrates that the average response time of the electronic device to process the class a IO request is longer than the average response time of the electronic device to process the class B IO request. This is not consistent with the expected minimum average response time for class a IO requests. The application program is as follows: the average response time of the electronic device 100 to process the IO requests initiated by the system class application is shorter than the average response time to process the IO requests initiated by the foreground class application. This is not in line with the expectations of the user.

Thus, when the above situation occurs, the electronic device 100 may allocate more IO resources for the class a IO request, so as to improve the average response time of the high-priority IO request. Specifically, the electronic device 100 may promote the scheduling ratio of the class a IO requests, so that the electronic device 100 processes more class a IO requests in a unit time. In this way, the average response time for a class A IO request may be reduced.

For example, in a scenario where the scheduling ratio is 5:3:2, in a scenario where 5 class a IO requests, 3 class B IO requests, and 2 class C IO requests are processed by 1ms, if AvgT2< AvgT1< AvgT3, the electronic device 100 may raise the scheduling ratio of the class a IO requests from 5 to 6, and correspondingly lower the ratio of the class B IO requests from 3 to 2, that is, the adjusted scheduling ratio is 6:2:2. Further, if more IO resources are to be provided for the class a IO request, the electronic device 100 may further adjust the scheduling ratio to 7:2:1.

Similarly, if AvgT1< AvgT3< AvgT2, the electronic device 100 may allocate a part of the IO resources of the class C IO request to the class B IO request, so as to increase the IO resource occupancy of the class B IO request, further increase the efficiency of the electronic device 100 in processing the class B IO request, and reduce the average response time of the class B IO request.

Here, the electronic device 100 does not adjust the IO resource occupancy of high priority. For example, the electronic device 100 may not allocate IO resources belonging to a class A IO request to a class B IO request. This is because: decreasing the IO resource occupancy of high priority IO requests and increasing the IO resource occupancy of low priority IO requests is highly likely to result in the average response time of high priority IO requests being lower than the average response time of low priority IO requests.

It can be appreciated that if the average response time of the high priority IO requests is lower than the average response time of the low priority IO requests, the electronic device 100 may maintain the current scheduling ratio.

In some embodiments, the electronic device 100 may also determine whether to adjust the preset schedule ratio by whether the response time of a single high priority IO request is lower than the response time of a low priority IO request. In some embodiments, electronic device 100 may also use the longest response time in a high priority IO request to compare to the shortest response time of a low priority IO request. The embodiments of the present application are not limited in this regard.

S204 the electronic device 100 checks the load of the central processing unit to determine whether to limit the return rate of the low priority IO requests.

Optionally, while adjusting the dispatch ratio according to the average response time, the electronic device 100 may also check the load of the central processor to determine whether to limit the return rate of low priority IO requests.

The electronic device 100 may periodically detect the load of the central processing unit (central processing unit, CPU) and determine whether the CPU is busy. If the CPU is busy, the electronic device 100 may limit the return rate of the processing results of the low priority IO requests.

In this way, the activity of the application or process that initiated the low priority IO request may be reduced until the processing result of the IO request by electronic device 100 is not received. Further, the application or process may have a reduced occupancy rate of CPU resources. Therefore, the electronic device 100 may provide more CPU resources for the IO request with high priority, so as to improve the efficiency of the electronic device 100 in processing the IO request with high priority.

A load threshold may be preset within the electronic device 100. The electronic device 100 may periodically obtain the current load of the CPU. Then, the electronic device 100 compares the current load with a preset load threshold. If the current load does not exceed the load threshold, the electronic device may confirm that the CPU is not busy. At this time, the electronic device 100 may not limit the return rate of low priority IO requests. If the current load exceeds the load threshold, the electronic device can confirm that the CPU is busy. At this time, the electronic device 100 may limit the return rate of the low-priority IO request, reduce the activity of the priority application or process, and provide more CPU resources for the high-priority application or process.

Specifically, the process of determining whether to limit the return rate of the low-priority IO processing result by the electronic device 100 and determining which priorities to limit the return rate of the low-priority IO processing result may refer to the description of fig. 4C, which is not repeated here.

Taking the processing result of IO3 (priority IO request) as an example, after processing IO3, the electronic device 100 may generate the processing result of the IO request. The processing result may be returned to Block along the original path. At this time, the Block may delay for a period of time, for example, 0.1ms, and then return the processing result to APP2 that initiates the IO request.

Since the time delay of the APP2 receiving the processing result of IO3, the running state of APP2 is correspondingly slowed down, i.e. the activity of APP2 is reduced. Like this, APP2 also can reduce the occupation of CPU resources to make foreground application (e.g., APP 1) can obtain more CPU resources, and then promote the efficiency of electronic device 100 processing APP 1.

In addition, the return rate of limiting IO requests from the return end processing can not only reduce the activity of low-priority application programs or processes, so that foreground application programs or processes obtain more CPU resources, but also fully utilize IO resources.

Specifically, if, after detecting an IO request with a low priority initiated by an application or a process, the electronic device 100 directly limits the rate at which the IO request is issued to a Block or a storage device. Then, under the condition that the IO resources are not tense, namely the number of IO requests received by the Block and the storage device does not reach the maximum limit of self-processing, the utilization rate of the IO resources can be obviously reduced, and the waste of the IO resources is caused to a certain extent.

In the embodiment of the present application, since the electronic device 100 limits the return rate of the IO request after responding to the IO request with a low priority, the method not only can fully utilize the existing IO resources, but also can avoid the waste of the IO resources.

It will be appreciated that in the process described in S202, the electronic device 100 determines that the average response time of the IO requests of different priorities is related to the return restriction policy of the return control module 214 in S204. In the embodiment of the present application, in the process that the delay detection module 211 detects the average response time of the IO requests with different priorities in one period, the scheduling ratio used by the packet quota module 213 and the return control policy used by the return control module 214 are determined actually according to the last detected average response time of the IO requests with different priorities.

S205: the electronic device 100 continues to process IO requests of different priorities according to the adjusted scheduling ratio and the adjusted return rate.

After determining the new dispatch ratio and after determining whether to limit the return rate of low priority IO requests, i.e., the new dispatch ratio and the new return control strategy. The electronic device 100 may process the subsequent IO requests awaiting processing according to the new policy, i.e., the new dispatch ratio and the return rate of the IO requests.

For example, in a scenario where the dispatch ratio is changed to 6:2:2, the electronic device 100 may process 6 class a IO requests, 2 class B IO requests, 2 class C IO requests within 1 ms. If the CPU load is too high, the electronic device 100 may further limit the return rate of the processing result after processing the class B IO request and/or the class C IO request, for example, delay 0.1ms to upload the processing result with low priority. The latency detection module 211 may then recalculate the response times of the individual IO requests, as well as the average response time of the IO requests of the same priority, to instruct the packet quota module 213 whether to update the schedule ratio again.

In some embodiments, the electronic device 100 may also readjust the scheduling mix and return control strategy one or more cycles apart. The embodiments of the present application are not limited in this regard.

By implementing the input/output request processing method provided by the embodiment of the application, the electronic device 100 can detect the average response time of IO requests with different priorities in real time. When the average response time of the high-priority IO requests is higher than that of the low-priority IO requests, the electronic device 100 may adjust the ratio of the IO resources in time, so as to reduce the average response time of the high-priority IO requests and avoid the influence on the user experience caused by the overlong response time.

Besides directly increasing the occupancy rate of the IO resources of the IO requests with high priority, the electronic device 100 may further reduce the liveness of the application program with low latency requirements by limiting the return rate of the IO requests with low priority, so as to provide more CPU resources for the application program with high latency requirements, and increase the efficiency of the electronic device 100 in processing the application program requests. Meanwhile, the IO request with low priority is limited from the return end, so that the waste of IO resources can be avoided.

In the embodiment of the application, the following steps are included:

an IO request initiated by an application layer, and an input or read operation indicated by the request, may be referred to as an IO traffic.

In S201, the read/write scheduling module 215 may obtain the plurality of IO services with the priority of A, B, C from the cache queue A, B, C according to the preset scheduling ratio, which may be referred to as "take out the plurality of IO services from the plurality of queues".

In S202, the average response time of the electronic device compared with the different priorities may be referred to as "processing delay of one IO service".

In S204, the application program that returns the low-priority IO service after delaying for 0.1ms to initiate the IO service may be referred to as "the application program that returns the low-IO service after the processing result of the low-IO service with the processing priority is retained for the first time period".

In fig. 4C, the threshold H1 may be referred to as a first threshold.

In S201, the schedule ratio of 5:3:2 may be referred to as a first ratio; in S203, the schedule ratio of 6:2:2 may be referred to as a second ratio.

As used in the specification of the present application and the appended claims, the singular forms "a," "an," "the," and "the" are intended to include the plural forms as well, unless the context clearly indicates to the contrary. It should also be understood that the term "and/or" as used in this disclosure refers to and encompasses any or all possible combinations of one or more of the listed items. As used in the above embodiments, the term "when …" may be interpreted to mean "if …" or "after …" or "in response to determination …" or "in response to detection …" depending on the context. Similarly, the phrase "at the time of determination …" or "if detected (a stated condition or event)" may be interpreted to mean "if determined …" or "in response to determination …" or "at the time of detection (a stated condition or event)" or "in response to detection (a stated condition or event)" depending on the context.

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, produces a flow or function in accordance with embodiments of the present application, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by a wired (e.g., coaxial cable, fiber optic, digital subscriber line), or wireless (e.g., infrared, wireless, microwave, etc.). The computer readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that contains an integration of one or more available media. The usable medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk), etc.

Those of ordinary skill in the art will appreciate that implementing all or part of the above-described method embodiments may be accomplished by a computer program to instruct related hardware, the program may be stored in a computer readable storage medium, and the program may include the above-described method embodiments when executed. And the aforementioned storage medium includes: ROM or random access memory RAM, magnetic or optical disk, etc.

Claims

1. An input/output (IO) processing method applied to an electronic device, the method comprising:

taking out a plurality of IO services from a plurality of queues according to a first ratio, wherein one queue is used for storing one or more IO services with the same IO processing priority, and the IO processing priorities of the IO services stored in different queues are different;

IO processing is carried out on the plurality of extracted IO services according to the order of the IO processing priority from high to low;

determining processing time delay of the plurality of IO services in the IO processing, wherein the processing time delay of one IO service is used for indicating time consumption of the one IO service from detection of arrival of the one IO service to receiving of an IO processing result of the one IO service by an application program;

The second time, take out a plurality of IO business from a plurality of said queues according to the second ratio; the second time is subsequent to the first time;

under the condition that the processing time delay of the IO service with high IO processing priority is longer than that of the IO service with low IO processing priority, the value of the item corresponding to the IO service with high IO processing priority in the second ratio is increased; and under the condition that the processing time delay of the IO service with high IO processing priority is lower than that of the IO service with low IO processing priority, the second ratio is equal to the first ratio.

2. The method of claim 1, wherein when the number of IO traffic stored in a queue is less than the number of IO traffic indicated by the corresponding entry in the first ratio, the value of the corresponding entry in the second ratio is lower than the value of the corresponding entry in the first ratio.

3. The method of claim 1, wherein after retrieving the plurality of IO traffic from the plurality of queues at the second ratio, the method further comprises:

and after the processing result of the IO service with the low IO processing priority is retained for a first time, returning the processing result to an application program for issuing the IO service.

4. The method of claim 3, wherein the step of returning the processing result of the IO service with the low IO processing priority to the application program that issues the IO service after the processing result is retained for a first period of time specifically includes:

determining the current load of a Central Processing Unit (CPU) of the electronic equipment;

if the current load is higher than a first threshold, the processing result of the IO service with the low IO processing priority is retained for a first time and then returned to an application program for issuing the IO service, wherein the first threshold is preset.

5. The method of claim 1, wherein a first number of the plurality of queues is used to store IO traffic issued by a foreground application, and wherein queues other than the first number of queues are used to store IO traffic issued by a background application.

6. The method of claim 5, wherein the IO processing priority of the IO traffic is determined based on a processing delay of the IO traffic.

7. The method of claim 1, wherein the fetching the plurality of IO traffic from the plurality of queues at the first ratio comprises:

the number of the extracted IO services is equal to or greater than the sum of the numerical values of the proportion items of the first ratio, and the ratio of the number of IO services with different IO processing priorities in the extracted IO services is consistent with the first ratio;

Or, the number of the plurality of IO services is smaller than the sum of the numerical values of the proportion items of the first ratio.

8. The method according to claim 1, wherein the processing delay of the IO traffic with high IO processing priority specifically comprises any one of the following:

processing delay of one IO service taken out from a queue storing the high IO processing priority IO service;

and the average value of the processing time delay of all IO services taken out from the queue storing the IO services with high IO processing priority.

9. An electronic device comprising one or more processors and one or more memories; wherein the one or more memories are coupled to the one or more processors, the one or more memories for storing computer program code comprising computer instructions that, when executed by the one or more processors, cause the method of any of claims 1-8 to be performed.

10. A computer readable storage medium comprising instructions which, when run on an electronic device, cause the method of any one of claims 1-8 to be performed.