An IO scheduling method and device based on a kylin operating system and a medium

Abstract

The application discloses an IO scheduling method and device based on a Kylin operating system and a medium, the method comprising the following steps: a BFQ scheduler receives a request, obtains a characteristic value of a process or a thread corresponding to the request, if the characteristic value meets a preset condition, adds the request to an interactive dispatch queue, if the characteristic value does not meet the preset condition, adds the request to other queues; dispatches the request in the interactive dispatch queue until the number of dispatched requests reaches a first value, clears the number of dispatched requests and waits for the completion of the dispatched request, then dispatches the request in other queues until the number of dispatched requests reaches a second value, clears the number of dispatched requests and waits for the completion of the dispatched request, returns to the step of dispatching the request in the interactive dispatch queue until all requests are dispatched. The application solves the problem of lag in starting an interactive application under heavy I / O load of the Kylin operating system.

Description

Technical Field

[0001] This invention relates to the field of computer application technology, and in particular to an I / O scheduling method, device and medium based on the Kylin operating system. Background Technology

[0002] In some application scenarios, the Kylin desktop operating system provides a poor user experience for interactive applications. This is mainly reflected in the following two points: (1) When using the multi-queue mq-deadline scheduler under the Kylin desktop operating system, large applications such as QiAnXin Browser or Firefox take longer to start under heavy I / O load, approximately six times longer than under idle load. After successful startup, there is significant lag when clicking on a link on the page for the first time. This is because the mq-deadline scheduler schedules requests. Under heavy I / O load, i.e., with a large number of write requests, since starting the browser is a read operation, according to the characteristics of read operations, it is necessary to wait for the current I / O to complete before dispatching the next I / O. Therefore, the mq-deadline scheduler will schedule the write requests first and then the read requests, thus causing these applications to be unable to start for a long time.

[0003] (2) When using a multi-queue BFQ scheduler under the Kylin desktop operating system. The BFQ scheduler allocates a queue to each process / thread and allocates budget and virtual completion time to each queue according to the weight of each queue and vtime. The scheduling of each queue is coordinated according to the virtual completion time. The BFQ scheduler will try to allocate bandwidth evenly to each process to avoid starvation of some processes. The BFQ scheduler will also automatically identify interactive processes and soft real-time processes. It will increase the weight value of the latter to reduce the latency of the former and give them priority in scheduling, thus improving the interactive experience. However, under a large I / O load, when starting an interactive application, the internal scheduling strategy of the BFQ scheduler may be: before completing a synchronous read I / O request of the interactive application Q, it is necessary to complete multiple asynchronous write I / O requests of the ordinary process P first. This results in interactive applications such as QiAnXin Browser or Firefox taking a long time to start successfully, about three times longer than when the browser is idle. After successfully starting, there may be slight lag when clicking on a link on the page for the first time. Summary of the Invention

[0004] The technical problem that this invention aims to solve is: the need for a special scheduling method for interactive applications to address the lag issue when launching interactive applications in the Kylin operating system under heavy I / O loads.

[0005] To address the technical problems existing in the prior art, this invention provides an I / O scheduling method, device, and medium based on the Kylin operating system, which can smoothly launch interactive applications under heavy I / O loads.

[0006] To solve the above-mentioned technical problems, the technical solution proposed by this invention is as follows: An I / O scheduling method based on the Kylin operating system includes the following steps: The BFQ scheduler receives a request, obtains the characteristic value of the process or thread corresponding to the request, and if the characteristic value meets the preset conditions, adds the request to the interactive dispatch queue; if the characteristic value does not meet the preset conditions, the request is added to another queue. Dispatch requests from the interactive dispatch queue until the number of dispatched requests reaches the first value. Then, reset the number of dispatched requests to zero and wait for the dispatched requests to complete. Then, dispatch requests from other queues until the number of dispatched requests reaches the second value. Then, reset the number of dispatched requests to zero and wait for the dispatched requests to complete. Return to the step of dispatching requests from the interactive dispatch queue until all requests have been dispatched.

[0007] Furthermore, the specific steps for dispatching requests in the interactive dispatch queue until the number of dispatched requests reaches a first value, then clearing the number of dispatched requests to zero and waiting for the dispatched requests to complete include: If the number of dispatched requests has not reached the first value, and there are requests in the interactive dispatch queue, the requests in the interactive dispatch queue are dispatched to the driver in turn, and the number of dispatched requests is incremented by one each time, waiting for the dispatched requests to be completed, until the number of dispatched requests has not reached the first value but there are no requests in the interactive dispatch queue, or the number of dispatched requests has reached the first value. If the number of dispatched requests has not reached the first value and there are no requests in the interactive dispatch queue, wait for the dispatched requests to be completed, and then execute the step of dispatching requests from other queues. If the number of dispatched requests reaches the first value, the number of dispatched requests is cleared to zero. The system waits for the requests dispatched in the interactive dispatch queue to be completed before proceeding with the step of dispatching requests from other queues.

[0008] Furthermore, the ratio of the first value to the second value is 4:1.

[0009] Furthermore, before the BFQ scheduler receives a request, it also includes the following steps: when the application's process or thread starts, it obtains its characteristic value and assigns it to the task corresponding to the process or thread. The larger the characteristic value, the higher the application's priority.

[0010] Furthermore, the specific steps for assigning values ​​in the task corresponding to the process or thread include: adding Interactive = x to the task corresponding to the process or thread, where the value of x is the aforementioned feature value; The specific steps for obtaining the feature value of the process or thread corresponding to the request include: obtaining the task corresponding to the process or thread corresponding to the request, and determining whether the value of Interactive in the task meets the preset conditions.

[0011] Furthermore, the preset condition specifically refers to the feature value being greater than 0.

[0012] Furthermore, it also includes the step of modifying the depth limit parameter, specifically: if there is a request in the interactive dispatch queue, modify the depth limit parameter to the target ratio; if there is no request in the interactive dispatch queue, restore the depth limit parameter to the original ratio.

[0013] Furthermore, the target ratio is 2 / 3 for read requests and 1 / 3 for other types of requests.

[0014] The present invention also proposes an I / O scheduling device for the Kylin operating system, including a computer device, the computer device being programmed or configured to execute any of the I / O scheduling methods based on the Kylin operating system described above.

[0015] The present invention also proposes a computer-readable storage medium storing a computer program programmed or configured to execute any of the IO scheduling methods based on the Kylin operating system described above.

[0016] Compared with the prior art, the advantages of the present invention are as follows: This invention adds requests from interactive processes to the interactive dispatch queue and prioritizes processing requests from the interactive dispatch queue, ensuring the smooth startup of interactive applications under heavy I / O loads. Furthermore, this invention alternately dispatches requests from the interactive dispatch queue with those from other queues, ensuring rapid response from interactive applications while preventing other application processes from starving. Finally, considering that under heavy I / O loads, write requests can easily consume tags in the queue, making it difficult for read requests to obtain tags, this invention also adjusts the BFQ scheduler depth limit for cases where there are requests in the interactive dispatch queue, ensuring that read requests can use sufficient tags. Attached Figure Description

[0017] Figure 1 This is a flowchart of an embodiment of the present invention.

[0018] Figure 2 This is a flowchart illustrating the interactive application process / thread statistics processing of an embodiment of the present invention.

[0019] Figure 3This is a flowchart illustrating the interactive dispatch queue processing of an embodiment of the present invention.

[0020] Figure 4 This is a flowchart illustrating the balanced dispatch request processing of an embodiment of the present invention. Detailed Implementation

[0021] The present invention will be further described below with reference to the accompanying drawings and specific preferred embodiments, but this does not limit the scope of protection of the present invention.

[0022] Before introducing specific embodiments of the present invention, the relevant terms are explained as follows: BFQ Scheduler: BFQ (Budget Fair Queueing) is a proportionally shared disk scheduler that ensures each application receives the disk throughput it needs, even as individual applications fluctuate. This score is established by assigning a fixed weight to each application. Specifically, when applications contend for disk space, the throughput score given to each competing application is guaranteed to be equal to the ratio of the application's weight to the sum of the weights of all competing applications. BFQ applications work as follows: Each time service is provided, a budget is allocated to each application. This budget is measured in sectors. Once an application is selected, it is granted exclusive disk access until it exhausts all its allocated budget or no longer receives service requests. BFQ calculates and schedules the budget to achieve high disk throughput and approximate perfectly fair service. BFQ also boasts high responsiveness.

[0023] MQ multi-queue: On multi-core CPUs, if a batch of processes access a storage device in a single queue, all processes will compete for a lock in the block-level request queue. If the storage device's processing speed is fast enough, this lock will become a bottleneck. Therefore, multi-queue was developed to distribute resource contention from a single request queue to multiple queues. Multi-queues are mainly divided into hard queues and soft queues. Soft queues are generally allocated one per core. Request scheduling, marking, and counting functions can be performed in each software queue. Based on this, each core directly sends requests to its corresponding software queue, thus avoiding the lock contention problem caused by a single request queue. Hardware queues are mainly responsible for matching with the underlying device drivers; that is, the number of hardware queues corresponds to the number of device drivers. They are responsible for sending requests from software queues to the driver layer.

[0024] We found that when the BFQ scheduler is scheduling synchronous requests, it needs to wait for the previous request to complete before sending the next synchronous request. Asynchronous requests, however, are sent in real-time without this waiting. Under heavy I / O loads, when a synchronous request is sent, the BFQ scheduler does not wait for it to complete before sending more requests. If the scheduling queue corresponding to the synchronous request is empty, it will dispatch the request to the next scheduling queue. Therefore, when multiple asynchronous or other synchronous requests from different queues are sent after a synchronous request, if the disk supports ncq, the waiting time for synchronous requests to complete will become very slow. This situation will worsen as requests from other queues are continuously dispatched.

[0025] Synchronous requests are generally read requests, while asynchronous requests are generally write requests. Interactive applications primarily use synchronous read requests at startup. Therefore, they can become sluggish under heavy I / O loads. When the system has a heavy I / O load, for example, if a regular process P is issuing a large number of asynchronous write I / O requests, and an interactive application Q happens to start, the BFQ internal scheduling strategy might generate the following I / O request dispatch sequence: 11111101111011111111 In this sequence, "1" represents an asynchronous write request from a normal process P, and "0" represents a synchronous read request from an interactive application Q. This dispatch sequence shows that to complete a synchronous read I / O request from the interactive application Q, multiple asynchronous write I / O requests from the normal process P must be completed first. This dispatch sequence arises because of the nature of read I / O requests. The driver may decide to prioritize serving the I / O requests of non-interactive applications Q (i.e., normal process P) before serving the I / O requests of the interactive application Q, thus delaying the arrival of new I / O requests from the interactive application Q. This problem worsens with increasing driver speed and queue depth. As the number of requests increases, the I / O requests of normal process P are consistently prioritized, causing significant delays for the interactive application Q and severe bandwidth loss. Ultimately, the interactive application Q takes a long time to start successfully, and even after successful startup, there may be slight stuttering when clicking a link on the page for the first time.

[0026] To address the above issues, we consider implementing an interactive dispatch queue by statistically analyzing the processes of all interactive applications. Requests in this queue are prioritized. Specifically, we create a separate interactive dispatch list within BFQ. When an interactive application process initiates an interactive task under heavy I / O load, BFQ adds the corresponding scheduling queue to the interactive dispatch list and prioritizes processing requests from that queue. This ensures that interactive applications can start smoothly even under heavy I / O load.

[0027] like Figure 1 As shown, based on the above concept, we propose an I / O scheduling method based on the Kylin operating system, including the following steps: S1) Interactive application process / thread statistics processing: such as Figure 2 As shown, when an application's process or thread starts, its characteristic value is obtained and assigned to the task corresponding to the process or thread. Interactive = x is added to the task corresponding to the process or thread, and the value of x is the characteristic value. Applications with a characteristic value greater than 0 are interactive applications, and applications with a larger characteristic value have higher priority. Applications with a characteristic value of 0 are non-interactive applications. S2) Interactive dispatch queue processing: such as Figure 3 As shown, the BFQ scheduler receives a request, obtains the task corresponding to the process or thread of the request, and determines whether the Interactive value, i.e. the feature value, in the task meets a preset condition. If the feature value meets the preset condition, the request is a request from a process or thread of an interactive application that needs to be scheduled with priority, and the request is added to the interactive dispatch queue. If the feature value does not meet the preset condition, the request is a request from a process or thread of a non-interactive application that does not need to be scheduled with priority, and the request is added to another queue. S3) Balanced distribution processing: such as Figure 4 As shown, requests in the interactive dispatch queue are dispatched until the number of dispatched requests reaches the first value. The number of dispatched requests is then cleared to zero, and the dispatched requests are waited for to complete. Then, requests in other queues are dispatched until the number of dispatched requests reaches the second value. The number of dispatched requests is then cleared to zero, and the dispatched requests are waited for to complete. The process then returns to the step of dispatching requests in the interactive dispatch queue until all requests have been dispatched.

[0028] The following situations exist when dispatching requests from the interactive dispatch queue: If the number of dispatched requests has not reached the first value, and there are requests in the interactive dispatch queue, then the requests in the interactive dispatch queue need to be dispatched to the driver layer in turn, and the number of dispatched requests is incremented by one each time, waiting for the dispatched requests to be completed, until the number of dispatched requests has not reached the first value but there are no requests in the interactive dispatch queue, or the number of dispatched requests has reached the first value. If the number of dispatched requests has not reached the first value and there are no requests in the interactive dispatch queue, then it is necessary to wait for the dispatched requests to complete before proceeding with the step of dispatching requests from other queues. Once the number of dispatched requests reaches the first value, the dispatched request count needs to be reset to zero. The process then waits for all requests dispatched in the interactive dispatch queue to complete before proceeding with the dispatching of requests from other queues. Therefore, as Figure 4 As shown, during balanced dispatch processing, the status of requests dispatched by the interactive dispatch queue is first assessed. If the number of dispatched requests exceeds the set first limit, and the dispatched requests have been completed, the dispatch count is reset to 0, and no more requests will be dispatched to the interactive dispatch queue. Instead, requests from other queues will be dispatched. Furthermore, before dispatching requests to other queues, it is necessary to check whether the dispatched requests have been completed. If completed, the process can return to other queues for request dispatch. If not completed, the process needs to wait for requests dispatched by the interactive application process / thread.

[0029] When the number of requests dispatched by the interactive dispatch queue has not reached the first limit, it means that requests in the interactive dispatch queue can continue to be dispatched. If there are still requests in the interactive dispatch queue, they are directly dispatched to the driver layer, and the dispatched request count is incremented by one. If there are no remaining requests in the interactive dispatch queue, it is checked whether the dispatched requests have been completed and returned from the driver layer. If not, no requests are dispatched at this time, and requests dispatched for the interactive application process / thread need to wait. If completed, it directly returns to other queues and dispatches requests from other queues.

[0030] The control process for dispatching requests to other queues is similar to that of the interactive dispatch queue, except that the limit on the number of requests dispatched by other queues is different, set to a second value. Based on multiple tests, we set the ratio of the first value to the second value to 4:1, meaning that for every 4 requests dispatched from the interactive dispatch queue, one request is dispatched from one of the other queues. This ensures that other queues are not starved while also guaranteeing that the applications corresponding to requests from the interactive dispatch queue can respond quickly.

[0031] Furthermore, as mentioned earlier, due to the specific nature of read I / O requests, the driver may decide to prioritize serving the I / O requests of ordinary process P within the driver before serving the I / O requests of interactive application Q. Even when interactive application Q has not yet requested any requests and there is no available scheduling for it, the largely uncontrolled I / O volume from ordinary process P may still be scheduled, potentially causing a longer delay in I / O service for interactive application Q within the driver. Therefore, before dispatching requests from other queues, it is necessary to wait for the requests dispatched in the interactive dispatch queue to complete.

[0032] In this embodiment, if the BFQ scheduler detects the existence of an interactive application process / thread, it needs to modify the depth limit; otherwise, the depth limit is restored to its original value. Given the pre-allocated requests across multiple queues in the BFQ scheduler, under heavy I / O loads, write requests can easily consume all tags in the multiple queues, making it difficult for read requests to obtain available tags. Therefore, the BFQ scheduler has a set of depth limit parameters. When an interactive application process / thread is detected (i.e., a request exists in the interactive dispatch queue), the depth limit is modified so that read requests occupy 2 / 3 and other types of requests occupy 1 / 3. If no request exists in the interactive dispatch queue, the depth limit parameter is restored to its original proportion.

[0033] This embodiment also proposes an I / O scheduling device for the Kylin operating system, including a computer device, which is programmed or configured to execute any of the I / O scheduling methods based on the Kylin operating system described above. Specifically: 1. The following steps are executed during the interactive application process / thread statistics processing: (1) Obtain the characteristic value when the interactive process / thread starts; (2) Add the feature value to the task of the process / thread for recording; 2. The following steps are performed during the interactive dispatch queue processing: (1) Determine whether the request coming to the BFQ scheduler belongs to the interactive process / thread (by checking whether the feature value is greater than 0). If yes, execute (2). (2) Add the request for the interactive process / thread to the interactive dispatch queue; 3. The following steps are performed during the balanced distribution request processing: (1) Determine whether the number of dispatch requests in the special interactive dispatch queue has reached the limit. If yes, execute (2); otherwise, execute (3). (2) Determine whether the request dispatched by the special interactive dispatch queue is still incomplete in the driver layer. If yes, execute (4); otherwise, execute (5). (3) Obtain a request from the special interactive dispatch queue and dispatch it. If the request exists, execute (6); otherwise, execute (7). (4) Return directly, no request scheduling is performed this time, allowing the interactive application to idle; (5) The interactive application request dispatch count is cleared to 0, and the request is directly returned to retrieve requests from other queues for dispatch. (6) Directly dispatch the request to the driver layer and increment the interactive application request dispatch count by one; (7) Determine whether the interactive application's request is still incomplete in the driver layer or whether it needs to wait idly. If yes, execute (4); otherwise, execute (8). (8) Return directly and select another queue to dispatch the request.

[0034] The present invention also proposes a computer-readable storage medium storing a computer program programmed or configured to execute any of the IO scheduling methods based on the Kylin operating system described above.

[0035] In summary, the advantages of this invention are: 1. Independent and controllable: The design and implementation of the optimization algorithm are all independently designed and developed.

[0036] 2. The originality of the implementation method: This invention can effectively improve the response speed of interactive applications under the Kylin operating system. In the early stage of process loading, process feature values ​​are extracted, and then it is determined whether the process is one that needs performance improvement based on the process feature values. In the scheduler, such processes that need performance improvement are given priority scheduling and are idle, which is more targeted.

[0037] 3. The results are significant. Through analysis of the BFQ scheduler, the fast response performance of interactive applications under the Kylin operating system is improved in a more targeted manner.

[0038] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the invention. Therefore, any simple modifications, equivalent changes, and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention should fall within the protection scope of the present invention.

Claims

1. A method for IO scheduling based on a Kylin operating system, characterized in that, Includes the following steps: When an application's process or thread starts, its characteristic value is obtained and assigned to the corresponding task of the process or thread. The specific steps for assigning the value to the corresponding task of the process or thread include: adding Interactive = x to the corresponding task of the process or thread, where the value of x is the characteristic value. The larger the characteristic value, the higher the application priority. The BFQ scheduler receives a request and obtains the characteristic value of the process or thread corresponding to the request. The specific steps for obtaining the characteristic value of the process or thread corresponding to the request include: obtaining the task corresponding to the process or thread corresponding to the request, determining whether the value of Interactive in the task meets a preset condition, adding the request to the interactive dispatch queue if the characteristic value meets the preset condition, and adding the request to another queue if the characteristic value does not meet the preset condition. Dispatch requests from the interactive dispatch queue until the number of dispatched requests reaches the first value. Then, clear the number of dispatched requests to zero and wait for the dispatched requests to be completed in the driver layer. Then, dispatch requests from other queues until the number of dispatched requests reaches the second value. Then, clear the number of dispatched requests to zero and wait for the dispatched requests to be completed. Return to the step of dispatching requests from the interactive dispatch queue until all requests have been dispatched.

2. The IO scheduling method based on the Kirin operating system according to claim 1, wherein, The specific steps for dispatching requests from the interactive dispatch queue until the number of dispatched requests reaches a first value, then clearing the number of dispatched requests to zero and waiting for the dispatched requests to be completed in the driver layer include: If the number of dispatched requests has not reached the first value, and there are requests in the interactive dispatch queue, the requests in the interactive dispatch queue are dispatched to the driver layer in turn, and the number of dispatched requests is incremented by one each time. Wait for the dispatched requests to be completed until the number of dispatched requests has not reached the first value but there are no requests in the interactive dispatch queue, or the number of dispatched requests has reached the first value. If the number of dispatched requests has not reached the first value and there are no requests in the interactive dispatch queue, wait for the dispatched requests to be completed, and then execute the step of dispatching requests from other queues. If the number of dispatched requests reaches the first value, the number of dispatched requests is cleared to zero. The system waits for the requests dispatched in the interactive dispatch queue to be completed before proceeding with the step of dispatching requests from other queues. 3.The IO scheduling method based on the Kirin operating system according to claim 1, wherein, The ratio of the first value to the second value is 4:

1.

4. The IO scheduling method based on the Kirin operating system according to claim 1, wherein, The preset condition is specifically that the feature value is greater than 0.

5. The IO scheduling method based on the Kirin operating system according to claim 1, wherein, It also includes the step of modifying the depth limit parameter, specifically: if there is a request in the interactive dispatch queue, modify the depth limit parameter to the target ratio; if there is no request in the interactive dispatch queue, restore the depth limit parameter to the original ratio.

6. The IO scheduling method based on the Kirin operating system according to claim 5, characterized in that, The target ratio is 2 / 3 for read requests and 1 / 3 for other types of requests.

7. An IO scheduling apparatus of a QNX operating system, characterized in that, The invention includes a computer device that is programmed or configured to perform the I / O scheduling method based on the Kylin operating system as described in any one of claims 1 to 6.

8. A computer-readable storage medium, characterized in that, The storage medium stores a computer program that is programmed or configured to execute the I / O scheduling method based on the Kylin operating system as described in any one of claims 1 to 6.

Images