CN115729684A

CN115729684A - Input/output request processing method and electronic equipment

Info

Publication number: CN115729684A
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-03-03
Anticipated expiration: 2041-08-25
Also published as: CN114443240B; CN114443240A; CN115729684B

Abstract

The application provides an input/output request processing method and electronic equipment. The method can be applied to electronic equipment which has storage capacity and needs frequent read-write operation, such as mobile phones, tablet computers and the like. By implementing the method, the electronic device can detect the average response time of IO requests with different priorities in real time. When the average response time of the IO request with the high priority is longer than the average response time of the IO request with the low priority, the electronic device may increase the IO allocation ratio of the high priority group and decrease the IO allocation ratio of the low priority group. Therefore, in the same time, the electronic equipment can process more high-priority IO requests, so that the number of the waiting high-priority IO requests is reduced, the average response time of the high-priority IO requests is lower than that of the low-priority IO requests, more IO resources are provided for foreground application, blocking is avoided, and the use experience of a user is improved.

Description

Input/output request processing method and electronic equipment

This application is a divisional application, filed as original application No. 202110983851.2, filed 2021, 25/08, 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 an input/output request processing method and an electronic device.

Background

In a scenario of running multiple application programs, a read-write scheduling module of an electronic device such as a mobile phone or a tablet computer may receive multiple read operation requests or write operation requests, i.e., input/output requests (IO requests for short) issued by the multiple application programs.

The existing priority-based IO request scheduling method guarantees the requirement that the bottom layer equipment preferentially responds to the IO request issued by the foreground application, 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 other operations accompanying different types of read and write operations, such as encryption, decryption, compression, decompression, data verification, etc., the response time of the high-priority IO request is still higher than that of the low-priority IO request.

That is, the simple priority-based IO request scheduling method cannot guarantee that the IO request with high priority has a low average response time. That is, under the condition of preferentially processing the IO request with high priority issued by the foreground application, the occupation of the IO resource by the application running in the background still has a great influence on the foreground application.

Disclosure of Invention

The application provides an input/output request processing method and electronic equipment. The electronic device implementing the input/output IO request processing method can detect the IO service processing time of different priorities processed by the electronic device 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 on 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, taking out a plurality of IO services from a plurality of queues; in the 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; carrying out IO processing on the plurality of extracted IO services according to the IO processing priority; determining the 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 the time consumed by the IO service from the detection of the arrival of one IO service to the receiving of an IO processing result of one IO service by an application program; at the second time, taking out a plurality of IO services from the plurality of queues; the second time is after the first time; and if the processing delay of the IO service with the high IO processing priority is longer than that of the IO service with the low IO processing priority, the proportion 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 device may detect, in real time, that the electronic device processes IO traffic processing times of different priorities. 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 more high-priority IO requests can be processed by the electronic device within the same time, the processing efficiency of the high-priority IO service is improved, and the user experience is influenced by overlong response time.

With reference to the embodiments provided in the first aspect, in some embodiments, after the fetching of the plurality of IO services 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 the first time, returning the processing result to the application program which initiates the IO service with the low IO processing priority.

By implementing the method provided by the embodiment, the electronic device can also reduce the activity of the application program with low time 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 embodiments provided in the first aspect, in some embodiments, after a processing result of an IO request with a low priority is retained for a first time period, the processing result is returned to an application program that initiates the IO request with the low priority, which specifically includes: determining the current load of a Central Processing Unit (CPU) of the electronic equipment; if the current load is higher than the first threshold, returning a processing result of the low-priority IO request to an application program initiating the low-priority IO request after the processing result is retained for a first time, 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 sufficient, the IO service cannot be processed in time due to insufficient CPU resources. Therefore, at this time, the electronic device may limit the return rate of the priority IO service, and reduce the activity of the application program with low delay requirement, such as background application, so as to ensure that the IO service with high priority has sufficient CPU resources.

With reference to the embodiments provided in the first aspect, in some embodiments, the taking out, at the first time, a plurality of IO services from a plurality of queues specifically includes: at the first time, taking out a plurality of IO services from a plurality of queues according to a first ratio; at the second time, the extracting of the plurality of IO services from the plurality of queues specifically includes: 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 may obtain different numbers of IO services according to a preset ratio, and the numbers of IO services with different priorities are different in the IO services with different numbers obtained at one time. Thus, when the above scaling is performed, the electronic device may correspondingly adjust the number of IO services with different priorities acquired at a time.

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

With reference to the embodiment provided by 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 the number of IO services for obtaining the high IO processing priority.

Compared with the method for acquiring the IO services with different priorities according to the first ratio, when the electronic device acquires the IO services with different priorities according to the second ratio, the electronic device may acquire more IO services with high priorities.

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

By implementing the method provided by the embodiment, the number of IO services with different priorities sequentially acquired by the electronic device may be equal to the numerical values of the proportional terms in the first ratio; or the ratio can be larger than the proportional term values in the first ratio, but is in a multiple relation with the proportional term values in the first ratio; when the number of IO services of a certain priority is less than the number indicated by the corresponding proportion item in the first ratio, the number of 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 the time delay specifically includes: the time consumed from the detection of the arrival of an IO service to the reception of an IO processing result of the IO service by the application program; or, the average value of the time consumption of the IO processing results of the plurality of IO services from the detection of the arrival of the plurality of IO services to the reception of the application program, where the plurality of IO services are IO services having the same IO processing priority as the one IO service.

With the method provided in the foregoing embodiment, when determining 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 may compare the actual processing delay of the high-priority IO service with the actual processing delay of the low-priority IO service, or compare the average processing delay of all IO services of the priority to which the high-priority IO service belongs 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 for storing computer program code comprising computer instructions which, 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 present application provides a computer-readable storage medium, which includes instructions that, when executed on an electronic device, cause the electronic device to perform the method described in the first aspect and any possible implementation manner of the first aspect.

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

It is understood that the electronic device provided by the second aspect, the computer storage medium provided by the third aspect, and the computer program product provided by the fourth aspect are all used for executing the method provided by the present application. Therefore, the beneficial effects achieved by the method can refer to the beneficial effects in the corresponding method, and are not described herein again.

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 diagram of a hardware structure of an electronic device according to an embodiment of the present disclosure;

3A-3B are software architecture diagrams of an electronic device provided by an embodiment of the present application;

fig. 4A-4B are schematic diagrams illustrating 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 illustrating an electronic device determining a return control policy according to an embodiment of the present application;

FIGS. 5A-5C are a set of schematic user interfaces provided by embodiments of the present application;

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

Detailed Description

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

An electronic device (hereinafter referred to as the electronic device 100) such as a mobile phone or a tablet computer can run a plurality of application programs simultaneously. An 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.

Fig. 1 illustrates the software architecture of the electronic device 100.

The software system of the electronic device 100 may employ a layered architecture, an event-driven architecture, a micro-core architecture, a micro-service architecture, or a cloud architecture. The embodiment of the present application takes an Android system with a hierarchical architecture as an example, and exemplarily illustrates a software structure of the electronic device 100.

The layered architecture divides the software into several layers, each layer having a clear role and division of labor. The layers communicate with each other through a software interface. Generally, the hierarchical architecture of Android includes: an application layer, a framework layer, a kernel layer, an Android runtime (Android runtime), a system library, and the like. In the 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, that is, hardware devices responding to each IO request, including various Storage devices, such as Multi Media Card (MMC)/Embedded multimedia card (eMMC), SCSI (Small Computer System Interface) hard disk drive \ Universal Flash Storage (UFS), and so on.

The application layer may be installed with a plurality of applications. Taking application 1 (APP 1) as an example, application 1 may initiate one or more IO requests in response to user operations. One IO request indicates one IO operation. The IO requests include a write request (write), a read request (read), a synchronization request (fsync), a write-back (writeback) request, a forced buffer flush request (flush), and the like. For example, in the process of playing a video, an application program performing the function of playing the video may initiate a read request, and in response to the read request, the application program may read video data stored in the storage, thereby playing the video.

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

The read-write scheduling layer comprises: a read-write scheduling layer that employs a Multi-queue (MQ) framework and a read-write scheduling layer that employs a Single-queue (SQ) framework. In this embodiment, the read-write scheduling layer may be a read-write scheduling layer under the MQ framework. Generally, the read-write scheduling layer may perform scheduling of IO requests using a complex Fair (queuing) scheduling algorithm. In addition, the scheduling algorithm also includes a read priority (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 and improve the user experience, the electronic device may mark the priority of the read/write request issued by the application programs of different types. For example, the electronic device may mark that a read-write request issued by an application program being operated by a user is a read-write request with a high priority, and a read-write request issued by an application program in a background running state is a request with a low priority. The application program operated by the user can be abbreviated as foreground application; the application program in the background running state may be referred to as background application for short.

Then, the read-write scheduling layer can determine the sequence of the read-write requests issued by the bottom layer device in response to each application program according to the priority of the read-write requests.

The priority-based IO request scheduling method ensures that the bottom layer equipment preferentially responds to the IO request issued by the foreground application, 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 the auxiliary operations accompanying the different types of read and write operations, such as encryption, decryption, compression, decompression, data verification, etc., the response time of the high priority IO request may still be higher than that of the low priority IO request.

As shown in fig. 1, the file system includes: virtual File Systems (VFS), fourth-generation extended File Systems (ext 4), flash-Friendly File Systems (F2 FS), and extensible Read-Only File Systems (EROFS), among others.

When the operation of writing (or writing out) data is executed, different types of file systems can simultaneously execute auxiliary operations on the written (or written out) data so as to improve the accuracy and safety 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) data to the memory through the F2FS, the electronic apparatus 100 needs to perform an encryption (or decryption) operation on the written (or written) data. At this time, the auxiliary operations such as encryption and decryption increase the time consumption of the electronic device 100 to process the IO request. Therefore, when a high-priority IO request involves multiple auxiliary operations of encryption, decryption, compression, and the like, the response time of the high-priority IO request may be longer than that of a low-priority IO request.

Thus, for a high priority IO request, the average response time may be higher than for a low priority IO request. That is to say, the simple priority-based IO request scheduling method cannot guarantee that the IO request with high priority has a low response time, which leads to user experience.

In order to further ensure that foreground applications obtain sufficient IO resources and reduce the average response time of high-priority read-write requests, an embodiment of the present application provides an input/output request processing method. The method can be applied to electronic equipment which has storage capacity and needs frequent read-write operation, such as mobile phones, tablet computers and the like. In the following description of the embodiments, the electronic device such as the mobile phone and the tablet computer is simply referred to as the electronic device 100.

The electronic device 100 may also be, but is not limited to, a mobile phone or a tablet computer, a desktop computer, a laptop computer, a handheld computer, a notebook computer, an ultra-mobile personal computer (UMPC), a netbook, a cellular phone, a Personal Digital Assistant (PDA), an Augmented Reality (AR) device, a Virtual Reality (VR) device, an 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 in 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 request with the high priority is longer than the average response time of the IO request with the low priority, the electronic device 100 may increase the IO allocation ratio of the high priority group and decrease the IO allocation ratio of the low priority group.

In this way, in the same time, the electronic device 100 may process more IO requests with high priority, thereby reducing the number of waiting IO requests with high priority, ensuring that the average response time of the IO requests with higher priority is lower than the average response time of the IO requests with low priority, providing more IO resources for foreground application, avoiding congestion, and improving user experience.

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

The electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a Universal Serial Bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, a Subscriber Identity Module (SIM) card interface 195, and the like. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light 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.

Processor 110 may include one or more processing units, such as: the processor 110 may include an Application Processor (AP), a modem processor, a Graphics Processing Unit (GPU), an Image Signal Processor (ISP), a controller, a video codec, a Digital Signal Processor (DSP), a baseband processor, and/or a neural-Network Processing Unit (NPU), etc. The different processing units may be separate devices or may be integrated into one or more processors.

The controller can generate an operation control signal according to the instruction operation code and the timing signal to complete the control of instruction fetching and instruction execution.

A memory may also be provided in 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 have just been used or recycled by the processor 110. If the processor 110 needs to reuse the instruction or data, it can be called directly from the memory. Avoiding repeated accesses reduces the latency of the processor 110, thereby increasing the efficiency of the system.

In some embodiments, processor 110 may include one or more interfaces. The interface may include an integrated circuit (I2C) interface, an integrated circuit built-in audio (I2S) interface, a Pulse Code Modulation (PCM) interface, a universal asynchronous receiver/transmitter (UART) interface, a Mobile Industry Processor Interface (MIPI), a general-purpose input/output (GPIO) interface, a Subscriber Identity Module (SIM) interface, and/or a Universal Serial Bus (USB) interface, etc.

The I2C interface is a bidirectional synchronous serial bus including a serial data line (SDA) and a Serial Clock Line (SCL). In some embodiments, processor 110 may include multiple sets of I2C buses. The processor 110 may be coupled to the touch sensor 180K, a charger, a flash, a camera 193, etc. through different I2C bus interfaces, respectively. For example: the processor 110 may be coupled to the touch sensor 180K through an I2C interface, so that the processor 110 and the touch sensor 180K communicate 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, processor 110 may include multiple sets of I2S buses. The processor 110 may be coupled to the audio module 170 through an I2S bus, enabling communication between the processor 110 and the audio module 170. In some embodiments, the audio module 170 may transmit the audio signal to the wireless communication module 160 through the I2S interface, so as to implement a function of receiving a call through a bluetooth headset.

The PCM interface may also be used for audio communication, sampling, quantizing and encoding analog signals. In some embodiments, the audio module 170 and the wireless communication module 160 may be coupled by 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, so as to implement a function of answering a call through a 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 used for asynchronous communications. The bus may be a bidirectional communication bus. It converts the data to be transmitted between serial communication and parallel communication. In some embodiments, a UART interface is generally 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 the audio signal to the wireless communication module 160 through a UART interface, so as to realize the function of playing music through a bluetooth headset.

MIPI interfaces may be used to connect processor 110 with peripheral devices such as display screen 194, camera 193, and the like. The MIPI interface includes a Camera Serial Interface (CSI), a Display Serial Interface (DSI), and the like. In some embodiments, processor 110 and camera 193 communicate through a CSI interface to implement the capture functionality of electronic device 100. The processor 110 and the display screen 194 communicate through the DSI interface to implement the display function of the electronic device 100.

The GPIO interface may be configured by software. The GPIO interface may be configured as a control signal and may also be configured 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, I2S interface, UART interface, MIPI interface, and the like.

The USB interface 130 is an interface conforming to the USB standard specification, and may 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 transmit data between the electronic device 100 and a peripheral device. And the method can also be used for connecting a headset and playing audio through the headset. The interface may also be used to connect other electronic devices, such as AR devices and the like.

It should be understood that the connection relationship between the modules according to the embodiment of the present invention is only illustrative, and is not limited to the structure of the electronic device 100. In other embodiments of the present application, the electronic device 100 may also adopt different interface connection manners or a combination of multiple interface connection manners in the above embodiments.

The charging management module 140 is configured to receive a charging input from a charger. The charger may be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 may receive charging input from a wired charger via the USB interface 130. In some wireless charging embodiments, the charging management module 140 may receive a 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 to connect the battery 142, the charging 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, and supplies power to 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 used to monitor parameters such as battery capacity, battery cycle count, battery state of health (leakage, impedance), etc. In some other embodiments, the power management module 141 may also be disposed in the processor 110. In other embodiments, the power management module 141 and the charging 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 can also be multiplexed to improve the utilization of the antennas. For example: the antenna 1 may be multiplexed as 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 including 2G/3G/4G/5G wireless communication applied to the electronic device 100. The mobile communication module 150 may include at least one filter, a switch, a power amplifier, a Low Noise Amplifier (LNA), and the like. The mobile communication module 150 may receive the electromagnetic wave from the antenna 1, filter, amplify, etc. the received electromagnetic wave, and transmit the electromagnetic wave to the modem processor for demodulation. The mobile communication module 150 may also amplify the signal modulated by the modem processor, and convert the signal into electromagnetic wave through the antenna 1 to radiate the electromagnetic wave. 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 disposed 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 a 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 passes the demodulated low frequency baseband signal to a 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 a sound signal through an audio device (not limited to the speaker 170A, the receiver 170B, etc.) or displays an image 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 modules, independent of the processor 110.

The wireless communication module 160 may provide a solution for wireless communication applied to the electronic device 100, including Wireless Local Area Networks (WLANs) (e.g., wireless fidelity (Wi-Fi) networks), bluetooth (bluetooth, BT), global Navigation Satellite System (GNSS), frequency Modulation (FM), near Field Communication (NFC), infrared (IR), and the like. The wireless communication module 160 may be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via the antenna 2, performs frequency modulation and filtering on 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, perform frequency modulation and amplification on the signal, and convert the signal into electromagnetic waves via the antenna 2 to radiate the electromagnetic waves.

In some embodiments, antenna 1 of electronic device 100 is coupled to mobile communication module 150 and antenna 2 is coupled to wireless communication module 160 so that electronic device 100 can communicate with networks and other devices through wireless communication techniques. The wireless communication technology may include global system for mobile communications (GSM), general Packet Radio Service (GPRS), code division multiple access (code division multiple access, CDMA), wideband Code Division Multiple Access (WCDMA), time-division code division multiple access (time-division code division multiple access, TD-SCDMA), long Term Evolution (LTE), BT, GNSS, WLAN, NFC, FM, and/or IR technologies, etc. The GNSS may include a Global Positioning System (GPS), a global navigation satellite system (GLONASS), a beidou navigation satellite system (BDS), a quasi-zenith satellite system (QZSS), and/or a Satellite Based Augmentation System (SBAS).

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

The display screen 194 is used to display images, video, and the like. The display screen 194 includes a display panel. The display panel may adopt a Liquid Crystal Display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (active-matrix organic light-emitting diode, AMOLED), a flexible light-emitting diode (FLED), a miniature, a Micro-oeld, a quantum dot light-emitting diode (QLED), and 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 a shooting function through the ISP, the camera 193, the video codec, the GPU, the display 194, the application processor, and the like.

The ISP is used to process the data fed back by the camera 193. For example, when a photo is taken, the shutter is opened, light is transmitted to the camera photosensitive element through the lens, the optical signal is converted into an electrical signal, and the camera photosensitive element transmits the electrical signal to the ISP for processing and converting into an image visible to naked eyes. The ISP can also carry out algorithm optimization on 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 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 to the photosensitive element. The photosensitive element may be a Charge Coupled Device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The light sensing element converts the optical signal into an electrical signal, which is then passed to the ISP where it is converted into a digital image signal. And the ISP outputs the digital image signal to the DSP for processing. The DSP converts the digital image signal into image signal in standard RGB, YUV and other formats. 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 digital image signals and other digital signals. For example, when the electronic device 100 selects a frequency bin, the digital signal processor is used to perform fourier transform or the like on the frequency bin energy.

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: moving Picture Experts Group (MPEG) 1, MPEG2, MPEG3, MPEG4, and the like.

The NPU is a neural-network (NN) computing processor that processes input information quickly by using a biological neural network structure, for example, by using a transfer mode between neurons of a human brain, and can also learn by itself continuously. Applications such as intelligent recognition of the electronic device 100 can be realized through the NPU, for example: image recognition, face recognition, speech recognition, text understanding, and the like.

The internal memory 121 may include one or more Random Access Memories (RAMs) and one or more non-volatile memories (NVMs).

The random access memory may include static random-access memory (SRAM), dynamic random-access memory (DRAM), synchronous dynamic random-access memory (SDRAM), double data rate synchronous dynamic random-access memory (DDR SDRAM), such as fifth generation DDR SDRAM generally referred to as DDR5 SDRAM, and the like. The nonvolatile memory may include a magnetic disk storage device, a flash memory (flash memory).

The FLASH memory may include NOR FLASH, NAND FLASH, 3D NAND FLASH, etc. according to the operation principle, may include single-level cell (SLC), multi-level cell (MLC), triple-level cell (TLC), quad-level cell (QLC), etc. according to the level order of the memory cell, and may include universal FLASH memory (english: UFS), embedded multimedia memory Card (mc em), etc. according to the storage specification.

The random access memory may be read directly by the processor 110, may be used to store executable programs (e.g., machine instructions) for an operating system or other programs that are running, and may also be used to store data for user and application programs, etc.

The nonvolatile memory may also store executable programs, data of users and application programs, 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 an external nonvolatile memory to extend the storage capability of the electronic device 100. The external non-volatile memory communicates with the processor 110 through the external memory interface 120 to implement data storage functions. For example, files such as music, video, etc. are saved in an external nonvolatile memory.

In this embodiment of the present application, a storage device, which responds to an IO request issued by an application layer and executes an input/output operation matched with the IO request, includes: an internal memory 121 and an external memory interface 122.

The electronic device 100 may implement audio functions via the audio module 170, the speaker 170A, the receiver 170B, the microphone 170C, the headphone interface 170D, and the application processor. 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 some functional modules of the audio module 170 may be disposed in the processor 110.

The speaker 170A, also called a "horn", is used to convert the audio electrical signal into an acoustic signal. The electronic apparatus 100 can listen to music through the speaker 170A or listen to a handsfree call.

The receiver 170B, also called "earpiece", is used to convert the electrical audio signal into an acoustic signal. When the electronic apparatus 100 receives a call or voice information, it can receive voice by placing the receiver 170B close to the ear of the person.

The microphone 170C, also referred to as a "microphone," is used to convert sound signals into electrical signals. When making a call or sending voice information, the user can input a voice signal to the microphone 170C by uttering a voice signal close to the microphone 170C through the mouth of the user. 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 to achieve a noise reduction function in addition to collecting sound signals. In other embodiments, the electronic device 100 may further include three, four or more microphones 170C to collect sound signals, reduce noise, identify sound sources, perform directional recording, and so on.

The earphone interface 170D is used to connect a wired earphone. The earphone interface 170D may be the USB interface 130, or may be an Open Mobile Terminal Platform (OMTP) standard interface of 3.5 mm.

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 is also called 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 used to detect a touch operation applied thereto or nearby. The touch sensor can communicate the detected touch operation to the application processor to determine the touch event type. Visual output associated with the touch operation may be provided through the display screen 194. In other embodiments, the touch sensor 180K may be disposed on a surface of the electronic device 100, different from the position of the display screen 194.

In the embodiment of the present application, the electronic device 100 detects an operation applied to the screen of the mobile phone, for example, an operation of clicking an 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, and the like. The keys 190 may be mechanical keys. Or may be touch keys. The electronic apparatus 100 may receive a key input, and generate a key signal input related to user setting and function control of the electronic apparatus 100.

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

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

The SIM card interface 195 is used to connect a SIM card. The SIM card can be brought into and out of contact with the electronic apparatus 100 by being inserted into the SIM card interface 195 or being pulled out of the SIM card interface 195. 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 a Nano SIM card, a Micro SIM card, a SIM card, etc. The same SIM card interface 195 can be inserted with multiple cards at the same time. The types of the plurality of cards can 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 implement functions such as communication and data communication. In some embodiments, the electronic device 100 employs esims, namely: 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 is to be understood that the illustrated structure of the embodiment of the present invention does not specifically limit the electronic device 100. In other embodiments of the present application, electronic device 100 may include more or fewer components than shown in FIG. 2, or some components may be combined, some components may be split, or a different arrangement of components. The components shown in fig. 2 may be implemented in hardware, software, or a combination of software and hardware.

The following describes an input/output request processing method provided in the embodiment of the present application in detail.

On the basis of the software architecture of the electronic device 100 shown in fig. 1, the embodiment of the present application provides a schematic software architecture of the improved electronic device 100 shown in fig. 3A. The following is described in detail with reference to fig. 3A: in the process of implementing the input/output request processing method provided by the embodiment of the present application, the workflow of the software and the hardware of the electronic device 100 is implemented.

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 applications and a latency detection module 211. The one or more applications are, for example, application 1 (APP 1) and application 2 (APP 2). The application program may be an application program provided by the system, or may be a third-party application program.

In running an application, the application may initiate one or more processes. For example, in the process of running a video-audio application program to play a video, the process maintained by the application program 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, 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, after detecting that a process initiates an IO request, the delay detection module 211 may obtain a timestamp (initiation time) when the process initiates the IO request. After the input/output operation indicated by the IO request is executed, 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 completed the execution of the IO request. 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 for processing the IO request. The delay detection module 211 may perform group statistics on response times of a plurality of IO requests issued by the application layer according to the type of the priority, and further calculate an average response time of IO requests of the same priority.

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

The file system 212 reflects the method and form of organizing files on a storage device. Different file systems 212 organize and manage files in different forms. Before the storage device of the electronic device 100 executes the IO request issued by the application layer, the IO request passes through the file system 212. The file system 212 processes the IO request according to a form of organizing and managing files preset by itself, so that the IO request becomes data that is operable in a target storage space of the IO request.

For example, when the type of the file system 212 is F2FS, after receiving a certain IO request (an input request or an output request) issued by an 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) to the storage device more safely.

With reference to the description of FIG. 1, the file system 212 is of a wide variety of types. Due to the different methods of processing the IO request by different file systems 212, the IO request back-end delays through different file systems 212 are different. The back-end delay refers to the time consumed by the file system 212 to make the IO request into data that is operable in the target storage space of the IO request according to the method for organizing and managing files preset by the file system. The back-end delay is an important factor affecting the response time of the IO request.

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

The grouping quota module 213 may dynamically adjust an occupancy ratio of the IO requests of different priorities to the IO resources according to an average response time of the IO requests of different priorities, that is, dynamically adjust a scheduling ratio of the 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 a 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 order (i.e., the processing priority) of IO requests with different priorities processed by the electronic device 100 according to the scheduling policy preset by the packet quota module 213.

The following embodiments will describe the working principle of the packet quota module 213, the return control module 214, and the read-write scheduling module 215 in detail, which will not be expanded first.

The device layer includes a memory device 217. The storage device includes a volatile storage device and a non-volatile storage device. The nonvolatile storage device may be an SSD, an MMC/eMMC, or the like, which may specifically refer to the description in fig. 1 and will not be described herein. The controllable storage device 217 performs the input-output operation indicated by the IO request.

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

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

Generally, because the foreground application needs to give feedback to the user in time, the latency tolerance of the IO request initiated by the foreground application is low (i.e. the latency requirement is high). The delay tolerance mentioned above refers to the degree of delay of the received 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. The background application does not need immediate feedback to the user, so that the delay tolerance of the background application is high (i.e. the delay requirement is low). Upon detecting an IO request initiated by a background application, the electronic device 100 may be less urgent to process the IO request.

Therefore, after the IO request with higher delay requirement and the IO request with lower delay requirement are detected at the same time, the electronic device 100 may preferentially process the IO request with higher delay requirement.

For example, APP1 may initiate an IO request (IO 1); APP2 may initiate two IO requests (IO 2, IO 3). For example, 5ms is required for the delay of IO1, 10ms is required for the delay of io2, and 15ms is required for the delay of io3. Therefore, IO1 may be a high priority IO request, and IO2 and IO3 may be low priority IO requests. Wherein, IO2 may have a higher priority than IO3. I.e. priority IO1 is higher than IO2 is higher than IO3. Here, we use the priority A, B, C (a > B > C) to respectively represent the processing priorities of the electronic device 100 to process the above 3 IO requests. Wherein the priority of IO1 is A; the priority of IO2 is B; IO3 has a priority of C. It can be understood that the correspondence between the aforementioned latency requirement and the IO processing priority is merely an exemplary example, and should not be construed as a limitation to the embodiment of the present application.

In a scenario where the electronic device 100 is running the video application and the gallery application simultaneously: the video application in the background running state may initiate a write request to write downloaded video data (IO 3) into the storage device 217; IO2 may be an IO request initiated by some system application or process; the gallery application in the foreground running state may initiate a read request to read a picture (IO 1) from the storage device 217. It can be understood that the delay 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 program.

Taking IO1 as an example, after 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 APP2 initiates IO2 and IO3, that is, the respective initiation time of IO2 and IO3.

The IO request issued by the application layer passes through the file system and can reach a Block (Block). The time delay of this one issue can be denoted as Δ t1. With reference to the description of fig. 1, because the target storage spaces of different IO requests use different file organization forms, that is, different file systems through which IO requests pass are different, the value of Δ t1 of different IO requests is different. This is also an important factor in that the total delay for high priority may be longer than the total delay for low priority.

After the IO request reaches Block, the read-write scheduling module 215 may determine the order in which the underlying storage device 217 processes the IO request according to the priority to which the IO request belongs. The time it takes for the IO request to wait to be processed at the read/write scheduling module 215 may be noted as Δ t2. In this embodiment of the present application, the read-write scheduling module 215 further depends on the packet quota module 213 in the process of determining the sequence of the IO requests processed by the storage device 217.

Specifically, the packet quota module 213 and the read-write scheduling module 215 operate according to the following principles:

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, which is referred to as a scheduling ratio. The read-write scheduling module 215 may obtain a specific number of IO requests from the cache region that receives the IO requests issued by the application layer according to the scheduling ratio recorded in the packet quota module 213, and determine the order in which the specific number of IO requests are issued to the storage device 217.

FIG. 4A illustrates the process by which the read-write scheduling module 215 processes received IO requests according to the scheduling quota 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 an a queue, a B queue, and a C queue. The 3 queues are used for buffering the IO requests with different priorities of the 3 types. The queue A can be used for caching IO requests (class A IO requests) with the priority of A; the B queue can be used for caching IO requests with the priority of B (class B IO requests); the C queue may be used to buffer IO requests of priority C (C-class IO requests).

After detecting an 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 in a queue with a corresponding priority to wait for a response of the underlying storage device.

In conjunction with IO1 (a), IO2 (B), 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, electronic device 100 may insert IO2 into the B queue; upon detection of IO3, electronic device 100 may insert IO3 into the C queue.

It is understood that the priority type of the IO request in the electronic device 100 may also be in other forms, i.e. include more or less priority hierarchies, according to different division principles, or by merging or splitting the above-mentioned 3 types of priorities. Accordingly, electronic device 100 may mark IO requests initiated by different applications or processes according to the new priority classification. The embodiments of the present application do not limit this. In other embodiments, IO requests of different priorities may also be cached in one storage area.

Electronic device 100 may also include a dispatch queue Q. The dispatch queue Q is also used to buffer IO requests. IO requests dequeued from the A, B, and C queues may be buffered to dispatch queue Q. The order in which the IO requests are queued in the dispatch queue Q may indicate the order in which the storage devices 217 actually process the IO requests.

After IO1, IO2, IO3 arrive at the buffer queue, IO1, IO2, IO3 may wait in the buffer queue. At this point, the read-write scheduling module 215 may obtain the current scheduling quota to the packet quota module 213. Then, the electronic device 100 may sequentially call a corresponding number of a-type IO requests, B-type IO requests, and C-type IO requests from the a queue, the B queue, and the 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. Under the condition that IO requests with different priorities are cached in one storage area, the read-write scheduling module 215 may identify the IO requests according to the priority identifier of each IO request, and determine whether to store the IO requests into the scheduling queue Q.

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

For example, assume that the schedule ratio recorded in the packet quota module 213 is 5. At this time, in one period, according to the scheduling ratio, the read-write scheduling module 215 may obtain 5 class a IO requests, 3 class B IO requests, and 2 class C IO requests from the buffer queue A, B, C, respectively, and insert the IO requests into the scheduling queue Q in sequence. The 5 class a IO requests, 3 class B IO requests, and 2 class C IO requests respectively include IO1, IO2, and IO3 waiting in the buffer queue A, B, C. In other embodiments, according to the scheduling ratio of 5.

Then, the read/write scheduling module 215 may issue the various IO requests in the scheduling queue Q to the storage device 217 in sequence. In response to the IO request, the storage device 217 may perform the input/output operation indicated by the IO request.

Returning to fig. 3B, after the storage device 217 has processed the IO request, the storage device 217 may return a processing result of the IO request to the application program that initiated the IO request. The time taken for the memory device 217 to process the IO request may be noted as Δ t3. The time consumed by the storage device 217 for returning the IO request to the application program to receive the IO processing result can be recorded as Δ t4. The main factor affecting Δ t3 is the type of the memory device, and therefore, in the embodiment of the present application, the time for the memory device 217 to perform the input/output operation in response to different IO requests may be considered to be the same, i.e., Δ t3 of different IO requests may be considered to be the same.

For example, after the storage device 217 sequentially executes the input and 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 an acknowledgement character (e.g., ACK), and/or data that is input or output.

The IO processed results pass through the 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 then the return control module 214 may control the return rate of the processing result of the IO request with low priority according to the current return control policy.

With reference to the multiple 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 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 blocks labeled "IO" in FIG. 4B are different from the schematic of FIG. 4A, where 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 one IO request is processed by storage device 217.

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

Under 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 that the return rate of the IO processing result with the class C priority is limited, when the received IO processing result is a processing result of an IO request with the class a priority (or a processing result of an IO request with the class B priority), the return control module 214 may normally return the IO processing result to the application layer. When the received IO processing result is a processing result of an IO request with 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 extended. In this way, as the processing result of the IO request with low priority is delayed to be received, the activity of the application program initiating the IO request is reduced, and thus the efficiency of the electronic device 100 for processing the IO request with high priority is improved.

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

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

The electronic device 100 may determine the current load of the CPU through a function provided by the system for querying the operating state of the CPU, which is denoted as H0 and includes the occupation status of the CPU, the number of processes waiting for the CPU resource, and the like.

For example, when all processing cores of the CPU are occupied and there are a large number of processes waiting for processing by the CPU, the electronic apparatus 100 may determine that the CPU load is high (busy). The above functions are, for example, vmstat () function, mpstat () function, etc. provided by Linux, and the embodiments of the present application do not limit this.

The electronic device 100 may then compare the current load to a preset load threshold to 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 may reflect: the electronic device 100 limits the varying degrees of low priority IO request return rates. Of course, the electronic device 100 may also set more or less load thresholds. The embodiments of the present application do not limit this.

After acquiring the current load of the CPU, the electronic apparatus 100 may compare the current load with the load thresholds (H1, H2). First, S102: the electronic device 100 can 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: electronic device 100 may limit the return rate of all low priority IO requests (e.g., limit the return rate of IO requests of priority B and C). Embodied on the application, the electronic device 100 may limit the return rate of IO requests initiated by non-foreground applications, including IO requests of system applications and background applications.

If the current load is lower than H2, H0< H2, S104: the electronic device 100 may continue to compare the current load with the threshold H1, and 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: electronic device 100 may limit the return rate of portions of low priority IO requests (e.g., limit the return rate of only IO requests of priority C). Embodied on the application program, the electronic device 100 may limit only the return rate of the IO request initiated by the background class application program, but not the return rate of the IO request initiated by the 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 can reduce the CPU resource occupation of the background application by controlling the return rate of the IO request with low priority, and improve the foreground application processing performance. Meanwhile, the background application is limited from the return end, and the utilization rate of IO resources can be improved.

Returning to FIG. 3B, after passing through the return control module 214, the IO processing results may be returned to the application that initiated the IO request, passing through the file system 212, the latency detection module 211, and so on. For example, IO1 may return APP1, and 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 a time (end time) when the electronic device 100 has processed the IO request corresponding to the IO processing result. Similarly, 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 has processed IO 1. With reference to the foregoing description, after APP1 initiates IO1, the delay detection module 211 detects the time (initiation time) of IO1, and through the two times (initiation time and end time), the delay detection module 211 may determine the total time for the electronic device 100 to process IO1, that is, the response time, which is denoted as T1.

By analogy, the delay detection module 211 may sequentially determine the time for the electronic device 100 to process the IO requests in one IO processing period, i.e., the response time of each IO request. Thus, 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, and therefore the response time of the class a IO requests should be the shortest. In IO1, IO2, IO3, the response time T1, T2, T3 of IO1, IO2, IO3 should satisfy: t1< T2< T3. However, due to the time consumption on the paths Δ t1, Δ t2, etc., especially different file systems 212 (different Δ t 2) passed by different IO requests, this may result in that the response time of the IO request with high priority is longer than that of the IO request with low priority. This is because different file systems handle data attachment differently (encryption, decryption, compression, decompression, data verification, etc.).

For example, Δ t1 of IO1 may be larger than Δ t1 of IO2 due to the encryption and compression operations, so the response time of IO1 is longer than that of IO 1.

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

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 times of the different IO requests satisfy: the response time of the high priority IO request is less than the response time of the low priority IO request.

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

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

Likewise, referring to the above processing method, the electronic device 100 may sequentially determine the average response time of the class B IO request and the class C IO request, which is 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 as AvgT1, avgT2, and AvgT3, respectively.

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

Taking the average response time as an example, after determining the AvgT1, avgT2, and 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 an average response time of the IO request 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 IO request with high priority is lower than the average response time of the IO request with low priority, the packet quota module 213 may determine that: the current efficiency of processing high priority IO requests cannot meet the demand that users want 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 request with high priority, that is, increase the ratio of high priority in the scheduling ratio, so as to further meet the requirement of foreground application, and avoid the influence of too long response time on user experience.

For example, in the case that the scheduling ratio is 5. In this way, the electronic device 100 can process 5 a-type IO requests from the original 1ms, and can process 6 a-type IO requests from the original 1 ms. In this way, the electronic device 100 may process more class a IO requests in the same unit time, and then 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 of the class B IO request and decrease the IO resource occupancy of the class C IO request, for example, the electronic device 100 may adjust the scheduling ratio (5.

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. Therefore, the electronic device 100 may readjust the allocation of the IO resources to allocate more IO resources for the high-priority IO request, so as to reduce the average response time of the high-priority IO request.

The packet quota module 213 may also adjust the scheduling ratio based on 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, and after it is determined that T1> T2, the packet quota module 213 may also increase the ratio of the items of IO1 in the scheduling matching, which may specifically refer to the above method for adjusting the average response time, and is not described here again.

In some embodiments, the number of class a IO requests may be reduced when the requirements of shutdown foreground applications or foreground applications for IO resources are significantly reduced. At this time, the electronic device 100 may readjust the scheduling ratio, appropriately reduce the proportion of the class a IO request to the IO resource, and increase the proportion of the class B IO request and the class C IO request.

For example, in the process that the electronic device 100 acquires each group of IO requests according to the scheduling ratio of 6. The embodiments of the present application do not limit this.

Of course, in other embodiments, when the requirement for IO resources for closing foreground applications or foreground applications is significantly reduced, the electronic device 100 may also continue to use the foregoing scheduling ratio, which is not described herein again.

Then, the read-write scheduling module can obtain IO requests with different priorities from the buffer queue A, B, C according to the new scheduling ratio.

In other embodiments, after obtaining the data in the delay detection module 211, the packet quota module 213 may check whether the response time of each IO request meets its own delay requirement. The packet quota module 213 may also adjust the scheduling ratios of different priorities when the response time does not meet its own latency requirement. For example, the response time of IO1 is 10ms, and the delay requirement of IO1 itself is 5ms, that is, the response time of IO1 does not meet the delay requirement of itself, at this time, the packet quota module 213 may increase the ratio of the priority to which IO1 belongs in the scheduling ratio.

It is to be understood that the illustrated structure of the embodiment of the present invention does not specifically limit the electronic device 100. In other embodiments of the present application, electronic device 100 may include more or fewer hierarchies and functional modules than shown in fig. 3A, or combine some of the hierarchies and functional modules, or split some of the hierarchies and functional modules, or different arrangements of the 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 the electronic device 100.

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

Wherein, the status bar 411 may include: one or more signal strength indicators for mobile communication signals (which may also be referred to as cellular signals), one or more signal strength indicators for high fidelity (Wi-Fi) signals, a battery status indicator, a time indicator, etc.

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

Icons for one or more applications may be displayed in the common application icon tray 413. The one or more applications are applications that are often used by the user and are set by the user, such as applications for cameras, address books, telephones, information, and the like. The application icons in the frequent application icon tray 413 remain displayed at the time of page switching. The tray icon is optional, and the embodiment of the present application does not limit this. Page indicator 414 can be used to indicate the positional relationship of the currently displayed page with 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 page the user is currently browsing for applications in. The user can slide the area of the other application icons side-to-side to browse the application icons in the other pages.

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

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

Fig. 5B shows a user interface for the electronic device 100 to run the 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 so forth.

The search bar 421 may be used to search for pictures. For example, the user may enter the keyword "flowers" in the search bar 421. The electronic apparatus 100 may detect a user operation acting on the search bar 421, and in response to this operation, the electronic apparatus 100 may search all pictures stored in the gallery for a picture whose picture content includes "flowers".

Icons 422 of one or more albums may represent one or more folders in which image data is stored. As shown in fig. 5B, the album includes a camera (Cmera), a screen shot (ScreenShot), a 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, after detecting the user operation 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 multiple 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. While displaying the user interface shown in FIG. 5B, the gallery application may initiate an IO request to read the control icon resource. Additionally, the gallery application may initiate an IO request to read an image 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, and videos stored in the electronic apparatus 100.

The electronic device 100 may detect an operation of clicking a certain application icon by a plurality of users, and in response to the user operation, the electronic device 100 may run a plurality of applications. For the above applications, some of the applications are the applications being operated by the user, i.e. foreground applications, and others are the applications running 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, electronic device 100 may detect a certain user operation, and in response to the operation, electronic device 100 may display an application that is running. For example, as shown in fig. 5B, the electronic apparatus 100 may detect an operation in which the user slides upward from the bottom of the screen. In response to the above operation, the electronic apparatus 100 may display the user interface illustrated in fig. 5C.

As shown in fig. 5C, the user interface includes a page 431. The page 431 may represent a gallery application (photo) that runs in response to the user operations shown in fig. 5A, 5B, previously described. In addition, the user interface includes

pages

432, 433. Page 432 may represent a running Browser application (Browser); the page 433 may represent a setting application (Settings) that is running.

Not limited to the browser application and the setup 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 operating directly) may be referred to as a foreground application. The browser application, the setting application, and other application programs that are not currently being directly operated by the user may be referred to as background applications.

The latency requirements for different IO requests may be different. Generally, the latency requirement of IO requests initiated by applications with low latency tolerance is high. The latency tolerance of foreground applications is low. Therefore, the latency requirement of the IO request initiated by the foreground application is high, i.e. the priority of the electronic device 100 to process such IO request is high. Electronic device 100 needs to handle this type of IO request as soon as possible. Compared with the IO request initiated by the foreground application, the IO request initiated by the background application has lower processing priority. 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.

Thus, 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 that IO requests with different delay requirements can all obtain responses of the electronic device 100 within respective delay requirements as much as possible.

Fig. 6 is a flowchart illustrating the electronic device 100 implementing the input/output processing method provided in the embodiment of the present application.

S201, the electronic device 100 processes IO requests with different priorities according to a preset scheduling ratio.

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

Specifically, with reference to fig. 3A, an IO request initiated by the application layer may be issued to the kernel layer Block. Typically, block receives multiple IO requests simultaneously. After receiving the IO request, the electronic device 100 may determine a latency requirement of the IO request. For an IO request with a high delay requirement, that is, an IO request requiring a response as soon as possible, block will preferentially issue the IO request to a storage driver (storage driver) stored in a target of the IO request.

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

For example, as shown in fig. 4A, the electronic device 100 may sequentially process 5 IO requests of high priority (a), 3 IO requests of medium priority (B), and 2 IO requests of low priority (C) in a unit time. In this unit time, after the electronic device 100 processes the IO request with the high priority, even if there are other IO requests with the high priority in the Block, the electronic device 100 may process part of the 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 may result in blocking the application program or the process that initiates the IO request.

In the case of ensuring that the IO requests with lower priority are not blocked, the electronic device 100 may allocate more IO resources to the IO requests with high priority as much as possible. This is often because the application or process that initiates the high priority IO request is mostly directly related to user operations. If the high response efficiency of the high-priority IO request is not guaranteed 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 IO requests of different priorities according to the preset scheduling ratio, the electronic device 100 may detect an average response time of IO requests of each priority in real time.

As shown in fig. 3A, the electronic device 100 may be preset with a latency detection module 211. The delay detection module 211 may calculate an average response time of IO requests of the same priority while the electronic device 100 processes IO requests of different priorities.

Specifically, after an IO request is initiated by an application program or a process in an application layer, the delay detection module 211 may determine a timestamp of the IO request initiated by the application program or the process, and mark the timestamp as the initiation time of the IO request. When the storage device of the electronic device 100 executes the input/output operation corresponding to the IO request according to the indication of the IO request, the application layer may receive a processing result returned by the device layer. At this time, the delay detection module 211 may determine a time when the electronic device 100 has processed 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 (response time) when the electronic device 100 has finished processing the IO request. According to the initiation time and the response time, the latency detection module 211 may determine a response time of the electronic device 100 for processing the IO request.

With reference to the schematic diagram shown in fig. 4A, in the process that the electronic device 100 executes 5 IO requests with priority a in the scheduling queue Q, the delay detection module 211 may determine response times of the 5 IO requests according to the foregoing method. Then, the latency detection module 211 may determine an average response time (AvgT 1) of the 5 IO requests of priority a.

Similarly, when IO requests with priorities B and C in the scheduling queue Q are executed, the delay detection module 211 may sequentially determine an average response time (AvgT 2) of the IO request with the priority B and an average response time (AvgT 3) of the IO request with the priority C. Typically, avgT1< AvgT2< AvgT3.

And S203, the electronic equipment 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 request with a high priority is higher than the average response time of the IO request with a low priority according to the average response time.

When the average response time of the IO request with the high priority is longer than the average response time of the IO request with the low priority, the electronic device 100 may determine that the IO resource currently allocated to the IO request with the high priority by the system cannot meet the requirement of the IO request with the high priority. Therefore, the electronic device 100 needs to allocate more IO resources for the high-priority IO request to increase the average response time of the high-priority IO request.

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

Therefore, when the above situation occurs, the electronic device 100 may allocate more IO resources for the class a IO request to increase the average response time of the high-priority IO request. Specifically, the electronic device 100 may improve 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 class A IO requests may be reduced.

For example, in a scenario that the scheduling ratio is 5. Further, if it is desired to provide more IO resources for the class a IO request, the electronic device 100 may further adjust the scheduling ratio to be 7.

Similarly, if AvgT1< AvgT3< AvgT2, the electronic device 100 may allocate a part of IO resources of the class C IO request to the class B IO request, so as to improve the IO resource occupancy of the class B IO request, further improve 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 apparatus 100 does not adjust the IO resource occupancy of the 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: the IO resource occupancy rate of the IO request with the high priority is reduced, and the IO resource occupancy rate of the IO request with the low priority is improved, which may cause the average response time of the IO request with the high priority to be lower than the average response time of the IO request with the low priority.

As can be appreciated, if the average response time of the IO requests with high priority is lower than the average response time of the IO requests with low priority, 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 scheduling ratio according to 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 of high priority IO requests to compare with the shortest response time of low priority IO requests. The embodiments of the present application do not limit this.

S204, the electronic device 100 checks the load of the central processing unit and determines whether to limit the return rate of the low-priority IO request.

Optionally, while adjusting the scheduling ratio according to the average response time, the electronic device 100 may further check the load of the central processing unit to determine whether to limit the return rate of the low-priority IO request.

The electronic device 100 may periodically detect a load of a 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 request.

Thus, before the processing result of the electronic device 100 processing the low-priority IO request is not received, the activity of the application or process that initiated the IO request may be reduced. Further, the CPU resource utilization rate of the application or process may be reduced. Therefore, the electronic device 100 may provide more CPU resources for the high-priority IO request, thereby improving the efficiency of the electronic device 100 in processing the high-priority IO request.

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 determine that the CPU is not busy. At this time, the electronic device 100 may not limit the return rate of the low priority IO requests. If the current load exceeds the load threshold, the electronic device may determine 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 program or process, and provide more CPU resources for the high-priority application program or process.

Specifically, the process of determining whether to limit the return rate of the IO processing result with the low priority and determining which IO processing results with the priorities should be limited by the electronic device 100 may refer to the description of fig. 4C, and details thereof are not repeated here.

Taking the processing result of IO3 (priority IO request) as an example, after IO3 is processed, the electronic device 100 may generate the processing result of the IO request. The processing result may be routed back to Block. At this time, block may delay for a period of time, for example, 0.1ms, and then return the processing result to APP2, where the application layer initiates the IO request.

Because the time that APP2 receives the processing result of IO3 is delayed, then, the running state of APP2 is correspondingly slowed down, that is, the activity of APP2 is reduced. Like this, APP2 also reduces CPU resource occupation, so that foreground application (for example, APP 1) can obtain more CPU resources, and then promote the efficiency that electronic device 100 processes APP 1.

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

Specifically, if an IO request with a low priority, which is initiated by an application or a process, is detected, the electronic device 100 directly limits the rate at which the IO request is issued to the Block or the storage device. Then, under the condition that the IO resources are not stressed, that is, the number of the IO requests received by the Block and the storage device does not reach the maximum limit of the self-processing, the utilization rate of the IO resources can be obviously reduced, thereby causing the waste of the IO resources 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 low priority, the method may not only fully utilize the existing IO resource, but also avoid waste of the IO resource.

It is understood that in the process described in S202, the electronic device 100 determines that the average response time of IO requests of different priorities is related to the return restriction policy of the return control module 214 in S204. In this embodiment of the application, in the process that the delay detection module 211 detects the average response time of 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 actually determined according to the average response time of the IO requests with different priorities detected last time.

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

After determining the new scheduling ratio and determining whether to limit the return rate of the IO request with low priority, the new scheduling ratio and the new return control policy are obtained. The electronic device 100 may process subsequent IO requests waiting to be processed according to the new policy, i.e., the new scheduling ratio and the return rate of the IO requests.

For example, in a scenario in which the scheduling matching ratio is changed to 6. If the CPU load is too high, the electronic device 100 may further limit the processing of the class B IO request, and/or the return rate of the processing result after the class C IO request, for example, delaying the uploading of the low-priority processing result by 0.1ms, and the like. Then, the latency detection module 211 may recalculate the response time of the IO requests and the average response time of the IO requests of the same priority to instruct the packet quota module 213 whether to update the scheduling quota again.

In some embodiments, the electronic device 100 may also readjust the schedule ratio and the return control strategy every one or more cycles. The embodiments of the present application do not limit this.

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 request with the high priority is longer than the average response time of the IO request with the low priority, the electronic device 100 may adjust the ratio of the IO resources in time, so as to reduce the average response time of the IO request with the high priority, and avoid the influence of too long response time on the user experience.

In addition to directly increasing the occupancy of the IO resource of the high-priority IO request, the electronic device 100 may further reduce the activity of the application program with low latency requirement by limiting the return rate of the low-priority IO request, so as to provide more CPU resources for the application program with high latency requirement, and increase the efficiency of the electronic device 100 for processing the application program request. Meanwhile, the IO request with low priority is limited from the return end, and waste of IO resources can be avoided.

In the embodiments of the present application:

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

In S201, the read-write scheduling module 215 obtains multiple IO services with a priority of A, B, C from the buffer queue A, B, C according to a preset scheduling ratio, which may be referred to as "taking multiple IO services out of multiple queues".

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

In S204, returning the application program initiating the IO service after delaying the IO service with low priority for 0.1ms may be referred to as "returning the processing result of the IO service with low IO processing priority to the application program initiating the IO service with low IO processing priority after staying for the first time period".

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

In S201, schedule ratio 5; in S203, schedule ratio 6.

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 otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and 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 of …", depending on the context. Similarly, the phrase "in determining …" or "if a (stated condition or event) is detected" may be interpreted to mean "if … is determined" or "in response to …" or "upon detection of (stated condition or event)" or "in response to detection of (stated condition or event)" depending on the context.

In the above embodiments, the implementation may be wholly or partially realized 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. The procedures or functions described in accordance with the embodiments of the application are all or partially generated when the computer program instructions are loaded and executed on a computer. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another, 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 wire (e.g., coaxial cable, fiber optic, digital subscriber line) or wirelessly (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device, such as a server, a data center, etc., that incorporates one or more of the 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), among others.

Those skilled in the art can understand that all or part of the processes in the methods of the embodiments described above can be implemented by a computer program, which can be stored in a computer readable storage medium and can include the processes of the method embodiments described above when executed. And the aforementioned storage medium includes: various media capable of storing program codes, such as ROM or RAM, magnetic or optical disks, etc.

Claims

1. An input/output (IO) processing method applied to an electronic device is characterized by comprising the following steps:

in a first time interval, taking out a plurality of IO services from a foreground queue and a background queue according to a first ratio,

the first ratio is the ratio of the number of the IO services taken out from the foreground queue to the number of the IO services taken out from the background queue; the foreground queue is a queue for storing IO (input/output) services of foreground application, the background queue is a queue for storing IO services of background application, and the processing priority of the IO services of the foreground application is higher than that of the IO services of the background application;

carrying out IO processing on the plurality of the taken IO services according to the IO processing priority;

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

in a second time interval, taking out a plurality of IO services from the foreground queue and the background queue according to a second ratio; the second time interval is subsequent to the first time interval; and when the processing delay of the IO service of the foreground application is longer than that of the IO service of the background application, the second ratio is higher than the first ratio.

2. The method according to claim 1, wherein the second ratio is equal to the first ratio in a case that a processing delay of an IO service of a foreground application is lower than a processing delay of an IO service of a background application.

3. The method according to claim 1 or 2, wherein the second ratio is lower than the first ratio in a case that the number of IO traffic of the foreground application stored in the foreground queue is smaller than the number of IO traffic of the foreground application indicated by the first ratio.

4. The method of claim 1, wherein after fetching the plurality of IO traffic from the foreground queue and the background queue at the second ratio, the method further comprises:

and after the processing result of the IO service of the background application is retained for the first time, returning the processing result to the background application.

5. The method according to claim 4, wherein the returning the processing result of the IO service of the background application to the background application after staying for the first time period specifically comprises:

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, returning a processing result of the IO service of the background application to the background application after the processing result is retained for a first time, wherein the first threshold is preset.

6. The method of any of claims 1-5, wherein the foreground queue comprises one or more queues and the background queue comprises one or more queues.

7. The method according to claim 6, wherein the processing delay requirements of the IO traffic corresponding to each queue in the background queue are different.

8. The method according to any one of claims 1 to 7, wherein the taking out the plurality of IO services from the foreground queue and the background queue according to the first ratio specifically includes:

the number of the plurality of IO services taken out is equal to or larger than the sum of numerical values of all proportional items of the first ratio, and the ratio of the number of the IO services applied by the foreground to the number of the IO services applied by the background in the plurality of IO services taken out is consistent with the first ratio;

or the number of the plurality of the IO services taken out is smaller than the sum of the numerical values of the proportional items of the first ratio.

9. The method according to any one of claims 1 to 8, wherein the processing delay of the IO service of the foreground application specifically includes:

processing delay of an IO service taken out from the foreground queue according to the first ratio;

and taking out the average value of the processing time delays of the plurality of IO services from the foreground queue according to the first ratio.

10. 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 for storing computer program code comprising computer instructions which, when executed by the one or more processors, cause performance of the method recited in any of claims 1-9.

11. A computer-readable storage medium comprising instructions that, when executed on an electronic device, cause performance of the method of any of claims 1-9.