CN116107749A - IO scheduling method, device and medium based on kylin operating system - Google Patents
IO scheduling method, device and medium based on kylin operating system Download PDFInfo
- Publication number
- CN116107749A CN116107749A CN202310128924.9A CN202310128924A CN116107749A CN 116107749 A CN116107749 A CN 116107749A CN 202310128924 A CN202310128924 A CN 202310128924A CN 116107749 A CN116107749 A CN 116107749A
- Authority
- CN
- China
- Prior art keywords
- requests
- dispatched
- request
- interactive
- value
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
- G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
- G06F9/5038—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the execution order of a plurality of tasks, e.g. taking priority or time dependency constraints into consideration
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/50—Indexing scheme relating to G06F9/50
- G06F2209/5021—Priority
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer And Data Communications (AREA)
Abstract
The invention discloses an IO scheduling method, device and medium based on a kylin operating system, wherein the method comprises the following steps: the BFQ scheduler receives a request, acquires a characteristic value of a process or a thread corresponding to the request, adds the request into an interactive dispatch queue if the characteristic value meets a preset condition, and adds the request into other queues if the characteristic value does not meet the preset condition; and dispatching the requests in the interactive dispatching queues until the dispatched request number reaches a first value, clearing the dispatched request number and waiting for the dispatched requests to finish, then dispatching the requests in other queues until the dispatched request number reaches a second value, clearing the dispatched request number and waiting for the dispatched requests to finish, and returning to the step of dispatching the requests in the interactive dispatching queues until all the requests are dispatched. The invention solves the problem of the locking of the kylin operating system for starting the interactive application under the heavy I/O load.
Description
Technical Field
The invention relates to the technical field of computer application, in particular to an IO scheduling method, device and medium based on a kylin operating system.
Background
The kylin desktop operating system experiences poor with interactive applications in some application scenarios. This is mainly manifested in the following two points:
(1) When a multi-queue mq-readline scheduler is employed under the kylin desktop operating system. Under the condition that the system has larger I/O load, the time for starting large-scale applications such as an Qiyan browser or a firefox browser is longer, the time spent is about 6 times that under the no-load condition, and after the system is successfully started, a serious clamping condition exists when links in a page are clicked for interaction for the first time. The mq-readline scheduler schedules the request, when a large I/O load exists, namely, when a large number of write requests exist, the browser is started to perform read operation, and according to the characteristics of the read operation, the current IO is required to be waited for completion to continue to dispatch the next IO, so that the mq-readline scheduler can schedule the read request after the write request is scheduled, and the applications cannot be started later.
(2) When a multi-queue BFQ scheduler is employed under the kylin desktop operating system. The BFQ scheduler allocates a queue for each process/thread, allocates budget and virtual completion time for each queue according to the weight size and vtime of each queue, and the scheduling of each queue is coordinated according to the virtual completion time. The BFQ scheduler can allocate uniform bandwidth to each process as much as possible, so that the condition that starvation exists in the process is avoided. The BFQ scheduler may also determine interactive processes as well as soft real-time processes for automation. The weight value is increased for the process, so that the delay of the process is reduced, the process is scheduled preferentially, and the interactive experience is improved. However, in the case of a large I/O load on the system, when the interactive application is started, the internal scheduling policy of the BFQ scheduler may be: before completing one synchronous read I/O request of the interactive application Q, multiple asynchronous write I/O requests of the normal process P need to be completed preferentially. Therefore, the interactive application programs such as the Qiyan browser or the firefox browser can be started successfully in a longer time, the time spent is about three times that of the idle condition, and after the successful start, a slight clamping condition can exist when the links in the page are clicked for interaction for the first time.
Disclosure of Invention
The technical problem to be solved by the invention is as follows: a special scheduling approach for interactive applications is needed to solve the problem of the kylin operating system getting stuck starting interactive applications under heavy I/O load.
Aiming at the technical problems existing in the prior art, the invention provides an IO scheduling method, device and medium based on a kylin operating system, which can smoothly start interactive application under heavy I/O load.
In order to solve the technical problems, the technical scheme provided by the invention is as follows:
an IO scheduling method based on a kylin operating system comprises the following steps:
the BFQ scheduler receives a request, acquires a characteristic value of a process or a thread corresponding to the request, adds the request into an interactive dispatch queue if the characteristic value meets a preset condition, and adds the request into other queues if the characteristic value does not meet the preset condition;
and dispatching the requests in the interactive dispatching queues until the dispatched request number reaches a first value, clearing the dispatched request number and waiting for the dispatched requests to finish, then dispatching the requests in other queues until the dispatched request number reaches a second value, clearing the dispatched request number and waiting for the dispatched requests to finish, and returning to the step of dispatching the requests in the interactive dispatching queues until all the requests are dispatched.
Further, the specific steps of dispatching the requests in the interactive dispatching queue until the dispatched request number reaches the first value, clearing the dispatched request number and waiting for the dispatched request to complete include:
if the number of the dispatched requests does not reach the first value and the requests exist in the interactive dispatch queue, sequentially dispatching the requests in the interactive dispatch queue to the driver, adding one to the number of the dispatched requests each time, and waiting for the completion of the dispatched requests until the number of the dispatched requests does not reach the first value but no requests exist in the interactive dispatch queue, or the number of the dispatched requests reaches the first value;
if the number of the dispatched requests does not reach the first value and no request exists in the interactive dispatch queue, waiting for the dispatched requests to be completed, and executing the step of dispatching the requests in other queues;
if the number of dispatched requests reaches the first value, the number of dispatched requests is cleared, the completion of the dispatched requests of the interactive dispatch queue is waited, and the step of dispatching the requests in other queues is executed.
Further, the ratio of the first value to the second value is 4:1.
Further, before the BFQ scheduler receives the request, the method further includes the following steps: when an application process or thread is started, the characteristic value is acquired and assigned to the task corresponding to the process or thread, and the application priority is higher when the characteristic value is larger.
Further, the specific steps of assigning values to the task corresponding to the process or the thread include: adding an interactive=x in a task corresponding to a process or a thread, wherein the value of x is the characteristic value;
the specific steps of obtaining the characteristic value of the process or the thread corresponding to the request comprise: obtaining a task corresponding to a process or a thread corresponding to the request, and judging whether the value of the Interactive in the task meets a preset condition.
Further, the preset condition is specifically that the characteristic value is greater than 0.
Further, the method further comprises the step of modifying the depth limiting parameter, and specifically comprises the following steps: if there is a request in the interactive dispatch queue, modifying the depth limit parameter to be the target proportion, and if there is no request in the interactive dispatch queue, recovering the depth limit parameter to be the original proportion.
Further, the target proportion is that the read request occupies 2/3, and other types of requests occupy 1/3.
The invention also provides an IO scheduling device of the kylin operating system, which comprises computer equipment, wherein the computer equipment is programmed or configured to execute any IO scheduling method based on the kylin operating system.
The invention also proposes a computer readable storage medium having stored therein a computer program programmed or configured to perform any of the kylin operating system based IO scheduling methods.
Compared with the prior art, the invention has the advantages that:
according to the invention, the request of the interactive process is added into the interactive dispatch queue, and the request of the interactive dispatch queue is preferentially processed, so that the smoothness of starting the interactive application under heavy I/O load is ensured; in addition, the invention alternately distributes the requests in the interactive distribution queue and other queues, so as to ensure the quick response of the interactive application and avoid starvation of the processes of other applications at the same time; finally, considering the situation that the read request is difficult to acquire the tag because the write request easily consumes the tag in the queue under the heavy I/O load, the invention adjusts the depth limit of the BFQ scheduler according to the situation that the request exists in the interactive dispatch queue so as to ensure that the read request can use enough tags.
Drawings
FIG. 1 is a flow chart of an embodiment of the present invention.
FIG. 2 is a flow chart of an interactive application process/thread statistics process according to an embodiment of the present invention.
FIG. 3 is a flow chart of an interactive dispatch queue process according to an embodiment of the present invention.
Fig. 4 is a flowchart of a balanced dispatch request processing according to an embodiment of the present invention.
Detailed Description
The invention is further described below in connection with the drawings and the specific preferred embodiments, but the scope of protection of the invention is not limited thereby.
Before describing particular embodiments of the present invention, related terms will be described as follows:
BFQ scheduler: BFQ (Budget Fair Queueing) is a proportional-shared disk scheduler that ensures that each application can achieve the required disk throughput even if each application fluctuates. This score is established by assigning each application a fixed weight. In particular, when an application contends for disk, the score that guarantees throughput to each competing application is equal to the ratio of the weight of the application to the sum of the weights of all competing applications. The BFQ application works as follows. Each time a service is provided, a budget is allocated to each application. The budget is measured in units of sectors. Upon selection of the application, the application will be granted exclusive disk access until the application runs out of all allocated budget or no more service requests. BFQ will calculate and plan budgets to achieve high disk throughput and approximately full fairness service. BFQ also has high response capability.
mq multiple queues: on a multi-core cpu, in a single queue, if there are a lot of processes accessing one storage device, all processes compete for a lock in the request_queue of the block layer, and if the processing speed of the storage device is fast enough, the lock becomes a bottleneck. Thus, multiple queues have evolved, the main idea being to spread the contention of resources on a single request queue over multiple queues. The multi-queues are mainly divided into hard queues and soft queues. Soft queues, typically a core, are allocated a soft queue. Request scheduling, adding marks, counting and other functions can be performed in each corresponding software queue. On the basis, each core directly sends the request to the corresponding software queue, so that the lock contention problem caused by a single request queue can be avoided. The hardware queues are mainly responsible for matching with the bottom device drivers, i.e. how many device drivers exist, and a corresponding number of hardware queues are configured. It sends the request responsible for from the software queue to the driver layer.
We find that when the BFQ scheduler needs to wait for the completion of the previous request during the scheduling process of the synchronous request, the next synchronous request is continuously issued, while the asynchronous request is sent in real time, and no waiting condition exists. Under heavy I/O load, when a synchronous request is sent, the BFQ scheduler will continue to issue the request without waiting for the synchronous request to be completed, and if the scheduling queue corresponding to the synchronous request has no request, the request of the next scheduling queue will be dispatched. Based on this, when one synchronization request is sent, a plurality of asynchronous or other queued synchronization requests continue to be sent, and if the hard disk supports ncq, the waiting time for the synchronization request becomes very slow. This situation becomes more severe as requests from other queues are continually served.
Synchronous requests are typically read requests and asynchronous requests are typically write requests. The interactive application is mainly synchronous read request when started. So that it becomes relatively stuck under heavy I/O loading. When the system has heavy I/O load, for example, a normal process P issues a lot of asynchronous write I/O, an interactive application Q just starts to start up, and the BFQ internal scheduling policy may generate the following I/O request dispatch sequence:
11111101111011111111
where "1" indicates an asynchronous write request of the normal process P, and "0" indicates a synchronous read request of the interactive application Q, and from the set of dispatch sequences, it can be seen that completing one synchronous read I/O request of the interactive application Q requires preferentially completing a plurality of asynchronous write I/O requests of the normal process P. The reason for this dispatch sequence is that due to the specificity of read I/O requests, the driver may decide to prioritize the I/O requests of the non-interactive application Q in the drive, i.e. requests of the normal process P, before servicing the I/O requests of the interactive application Q, thereby delaying the arrival of new I/O requests of the interactive application Q. This problem is exacerbated as the speed of the drive and the depth of the queue increases, because as the number of requests increases, I/O requests of the normal process P are always serviced preferentially, resulting in a long delay for the interactive application Q and a significant loss of bandwidth for the interactive application Q. Eventually, the interactive application Q waits for a long time before being started successfully, and after the successful start, a slight jamming condition may also exist when the links in the page are clicked for interaction for the first time.
To solve the above situation, we consider that after counting the progress of all interactive applications, we implement an interactive dispatch queue and preferentially dispatch the requests in the interactive dispatch queue, and specifically we create an independent interactive dispatch linked list inside the BFQ. When a process with an interactive application program starts interaction under the condition of heavy I/O load, a scheduling queue corresponding to the process of the interactive application program is added into an interactive dispatch linked list in BFQ, and the dispatch linked list is processed preferentially. So that the interactive application can be launched very smoothly even under heavy I/O loads.
Based on the above conception, as shown in fig. 1, we propose an IO scheduling method based on a kylin operating system, which includes the following steps:
s1) interactive application process/thread statistical processing: as shown in fig. 2, when a process or a thread of an application is started, a characteristic value is obtained and assigned to a task corresponding to the process or the thread, an interactive=x is added to the task corresponding to the process or the thread, the value of x is the characteristic value, the application with the characteristic value larger than 0 is an Interactive application program, and the higher the application priority with the characteristic value is, the application with the characteristic value 0 is a non-Interactive application program;
s2) interactive dispatch queue processing: as shown in fig. 3, the BFQ scheduler receives a request, acquires a task corresponding to a process or a thread corresponding to the request, determines whether a value of an Interactive in the task, that is, a feature value, meets a preset condition, if the feature value meets the preset condition, the request is a request of a process or a thread of an Interactive application program needing to be preferentially scheduled, adds the request into an Interactive dispatch queue, and if the feature value does not meet the preset condition, the request is a request of a process or a thread of a non-Interactive application program not needing to be preferentially scheduled, and adds the request into other queues;
s3) balanced dispatch processing: as shown in fig. 4, the requests in the interactive dispatch queue are dispatched until the number of dispatched requests reaches a first value, the number of dispatched requests is cleared and the dispatched requests are waited for completion, then the requests in the other queues are dispatched until the number of dispatched requests reaches a second value, the number of dispatched requests is cleared and the dispatched requests are waited for completion, and the step of dispatching the requests in the interactive dispatch queue is returned until all requests are dispatched.
There are several cases when a request in an interactive dispatch queue is dispatched:
the number of dispatched requests does not reach the first value, and the requests exist in the interactive dispatch queue, then the requests in the interactive dispatch queue need to be dispatched to the driver sequentially, and the number of dispatched requests is self-added each time, and the dispatched requests are waited for to be completed until the number of dispatched requests does not reach the first value but no requests exist in the interactive dispatch queue, or the number of dispatched requests reaches the first value;
the number of dispatched requests does not reach the first value, and no requests exist in the interactive dispatch queue, and then the dispatched requests need to be waited for to be completed, and the steps of dispatching the requests in other queues are executed;
the number of dispatched requests reaches a first value, at which time the number of dispatched requests needs to be cleared, waiting for completion of the dispatched requests in the interactive dispatch queue, and executing the step of dispatching requests in the other queues
Therefore, as shown in fig. 4, in the balanced dispatch process, the request situation dispatched by the interactive dispatch queue is first determined. If the dispatched request exceeds the limit of the set first value and the dispatched request is completed, the dispatched number is clear of 0, the request of the interactive dispatch queue is not continued to be dispatched, and the requests of other queues are dispatched. In addition, before dispatching the requests of other queues, it is necessary to determine whether the dispatched requests are completed, and if so, the requests can be returned to the other queues for dispatching. If not, a wait is required for the request dispatched for the interactive application process/thread.
When the number of requests served by the interactive serve queue does not reach the limit of the first value, it is stated that the requests in the interactive serve queue may continue to be served. If there are more requests in the interactive dispatch queue, then the dispatch is directly to the driver and the number of dispatched requests is self-increment. If there are no remaining requests in the interactive dispatch queue, it is determined whether the request it dispatched has returned from the driver completion. If not, no request is dispatched at this time, and the request dispatched for the interactive application process/thread needs to be waited. If so, the method directly returns to other queues and distributes requests of the other queues.
For the request dispatch of other queues, the control process is similar to that of the interactive dispatch queue, only the limit of the number of the requests dispatched by the other queues is different, and the second value is set as the ratio of the first value to the second value to be 4 according to multiple test experience: 1, i.e., each 4 requests of the interactive dispatch queue are dispatched, one request is dispatched from the other queue. Not only ensuring that other queues are not starved, but also ensuring that the application corresponding to the request of the interactive dispatch queue can respond quickly.
Furthermore, in accordance with the foregoing, due to the specificity of the read I/O request, the driver may decide to service the I/O request of the generic process P in the driver preferentially before servicing the I/O request of the interactive application Q, and when the interactive application Q is still not requesting to issue, and is not scheduled for idle, a substantially uncontrolled amount of I/O from the generic process P may also be scheduled, which may result in the I/O service of the interactive application Q being delayed in the driver for a longer period of time. It is therefore necessary to wait for the dispatched requests of the interactive dispatch queue to complete before executing the dispatch of the requests in the other queues.
In this embodiment, if the BFQ scheduler detects that there is still a process/thread of the interactive application, the depth constraint needs to be modified, and if not, the depth constraint directly restores the original value. According to the characteristic that the multiple queues of the BFQ scheduler are pre-allocated with requests, under the condition of heavy I/O load, the writing request can easily consume all the tags in the multiple queues, so that the reading request is difficult to acquire the available tags. Therefore, a set of depth limit parameters are arranged in the BFQ scheduler, when the process/thread of the interactive application is detected to exist, namely, the request exists in the interactive dispatch queue, the depth limit is modified to be 2/3 of the read request, 1/3 of other types of requests are occupied, and if no request exists in the interactive dispatch queue, the depth limit parameters are restored to be the original proportion.
The embodiment also provides an IO scheduling device of the kylin operating system, which comprises computer equipment, wherein the computer equipment is programmed or configured to execute any IO scheduling method based on the kylin operating system, and the method is specifically as follows:
1. the following steps are executed in the interactive application process/thread statistical processing process:
(1) When the interactive process/thread is started, acquiring a characteristic value of the interactive process/thread;
(2) Adding the characteristic value into the task of the process/thread for recording;
2. the following steps are executed in the processing process of the interactive dispatch queue:
(1) Judging whether the request coming to the BFQ dispatcher belongs to the request of the interactive process/thread (by judging whether the characteristic value is more than 0), if so, executing the step (2);
(2) Adding the request of the interactive process/thread to an interactive dispatch queue;
3. the following steps are executed in the process of processing the balanced dispatch request:
(1) judging whether the number of the dispatch requests of the special interactive dispatch queue reaches the limit, if so, executing (2), otherwise, executing (3);
(2) Judging whether the request dispatched by the special interactive dispatch queue is not complete in driving, if yes, executing (4), otherwise executing (5);
(3) Acquiring a request from a special interactive dispatch queue for dispatch, executing (6) if the request exists, and executing (7) if the request does not exist;
(4) Directly returning, wherein the request scheduling is not performed at this time, and idle is performed for the interactive application;
(5) The interactive application requests dispatch number clear 0, and directly returns to acquire requests from other queues for dispatch;
(6) Directly dispatching the request to the driver, and adding one to the interactive application request dispatch number;
(7) Judging whether the request of the interactive application is not completed in the driving or whether idle waiting is needed, if yes, executing (4), otherwise, executing (8);
(8) And directly returning, and selecting other queues to dispatch the request.
The invention also proposes a computer readable storage medium having stored therein a computer program programmed or configured to perform any of the kylin operating system based IO scheduling methods.
In summary, the present invention has the following advantages:
1. the design and the realization of the optimizing algorithm are all independent design and research and development.
2. The method and the device can effectively improve the response speed of the interactive application under the kylin operating system, judge whether the process is a process needing to improve the performance according to the process characteristic value by extracting the process characteristic value at the initial stage of process loading, and schedule the process needing to improve the performance in a scheduler in a priority manner, so that the scheduling is idle and more targeted.
3. The method has the advantages that the effect is obvious, and the quick response performance of the interactive application under the kylin operating system is improved more pertinently through the analysis of the BFQ scheduler.
The foregoing is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. While the invention has been described with reference to preferred embodiments, it is not intended to be limiting. Therefore, any simple modification, equivalent variation and modification of the above embodiments according to the technical substance of the present invention shall fall within the scope of the technical solution of the present invention.
Claims (10)
1. An IO scheduling method based on a kylin operating system is characterized by comprising the following steps:
the BFQ scheduler receives a request, acquires a characteristic value of a process or a thread corresponding to the request, adds the request into an interactive dispatch queue if the characteristic value meets a preset condition, and adds the request into other queues if the characteristic value does not meet the preset condition;
and dispatching the requests in the interactive dispatching queues until the dispatched request number reaches a first value, clearing the dispatched request number and waiting for the dispatched requests to finish, then dispatching the requests in other queues until the dispatched request number reaches a second value, clearing the dispatched request number and waiting for the dispatched requests to finish, and returning to the step of dispatching the requests in the interactive dispatching queues until all the requests are dispatched.
2. The kylin operating system based IO scheduling method of claim 1 wherein the specific steps of dispatching requests in the interactive dispatch queue until the number of dispatched requests reaches a first value, clearing the number of dispatched requests and waiting for the dispatched requests to complete comprise:
if the number of the dispatched requests does not reach the first value and the requests exist in the interactive dispatch queue, sequentially dispatching the requests in the interactive dispatch queue to the driver, adding one to the number of the dispatched requests each time, and waiting for the completion of the dispatched requests until the number of the dispatched requests does not reach the first value but no requests exist in the interactive dispatch queue, or the number of the dispatched requests reaches the first value;
if the number of the dispatched requests does not reach the first value and no request exists in the interactive dispatch queue, waiting for the dispatched requests to be completed, and executing the step of dispatching the requests in other queues;
if the number of dispatched requests reaches the first value, the number of dispatched requests is cleared, the completion of the dispatched requests of the interactive dispatch queue is waited, and the step of dispatching the requests in other queues is executed.
3. The kylin operating system based IO scheduling method of claim 1, wherein the ratio of the first value to the second value is 4:1.
4. The kylin operating system based IO scheduling method of claim 1 wherein before the BFQ scheduler receives the request, further comprising the steps of: when an application process or thread is started, the characteristic value is acquired and assigned to the task corresponding to the process or thread, and the application priority is higher when the characteristic value is larger.
5. The kylin operating system based IO scheduling method according to claim 4, wherein the specific step of assigning a value to a task corresponding to a process or thread comprises: adding an interactive=x in a task corresponding to a process or a thread, wherein the value of x is the characteristic value;
the specific steps of obtaining the characteristic value of the process or the thread corresponding to the request comprise: obtaining a task corresponding to a process or a thread corresponding to the request, and judging whether the value of the Interactive in the task meets a preset condition.
6. The kylin operating system-based IO scheduling method of claim 1, wherein the preset condition is specifically that the eigenvalue is greater than 0.
7. The kylin operating system based IO scheduling method of claim 1, further comprising the step of modifying a depth limiting parameter, specifically comprising: if there is a request in the interactive dispatch queue, modifying the depth limit parameter to be the target proportion, and if there is no request in the interactive dispatch queue, recovering the depth limit parameter to be the original proportion.
8. The kylin operating system based IO scheduling method of claim 7 wherein the target proportion is 2/3 of read requests and 1/3 of other types of requests.
9. An IO scheduling device for a kylin operating system, comprising computer equipment programmed or configured to perform the kylin operating system based IO scheduling method of any one of claims 1 to 8.
10. A computer readable storage medium having stored therein a computer program programmed or configured to perform the kylin operating system based IO scheduling method of any one of claims 1 to 8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310128924.9A CN116107749A (en) | 2023-02-16 | 2023-02-16 | IO scheduling method, device and medium based on kylin operating system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310128924.9A CN116107749A (en) | 2023-02-16 | 2023-02-16 | IO scheduling method, device and medium based on kylin operating system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116107749A true CN116107749A (en) | 2023-05-12 |
Family
ID=86255957
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310128924.9A Pending CN116107749A (en) | 2023-02-16 | 2023-02-16 | IO scheduling method, device and medium based on kylin operating system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116107749A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117435142A (en) * | 2023-12-12 | 2024-01-23 | 苏州元脑智能科技有限公司 | IO request scheduling method and storage device |
-
2023
- 2023-02-16 CN CN202310128924.9A patent/CN116107749A/en active Pending
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117435142A (en) * | 2023-12-12 | 2024-01-23 | 苏州元脑智能科技有限公司 | IO request scheduling method and storage device |
| CN117435142B (en) * | 2023-12-12 | 2024-03-01 | 苏州元脑智能科技有限公司 | IO request scheduling method and storage device |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7065766B2 (en) | Apparatus and method for load balancing of fixed priority threads in a multiple run queue environment | |
| US6748593B1 (en) | Apparatus and method for starvation load balancing using a global run queue in a multiple run queue system | |
| US6658449B1 (en) | Apparatus and method for periodic load balancing in a multiple run queue system | |
| Ghazalie et al. | Aperiodic servers in a deadline scheduling environment | |
| US8793695B2 (en) | Information processing device and information processing method | |
| US6560628B1 (en) | Apparatus, method, and recording medium for scheduling execution using time slot data | |
| Nurmi et al. | QBETS: Queue bounds estimation from time series | |
| Goel et al. | A comparative study of cpu scheduling algorithms | |
| US7076781B2 (en) | Resource reservation for large-scale job scheduling | |
| US20080086734A1 (en) | Resource-based scheduler | |
| US8799913B2 (en) | Computing system, method and computer-readable medium for managing a processing of tasks | |
| US20110035751A1 (en) | Soft Real-Time Load Balancer | |
| JPH1055284A (en) | Method and system for scheduling thread | |
| JPH07141305A (en) | Control method for execution of parallel computer | |
| CN109917705B (en) | Multi-task scheduling method | |
| CN116107749A (en) | IO scheduling method, device and medium based on kylin operating system | |
| US20030191794A1 (en) | Apparatus and method for dispatching fixed priority threads using a global run queue in a multiple run queue system | |
| CN106775975B (en) | Process scheduling method and device | |
| WO2007149224A1 (en) | Resource-based scheduler | |
| CN111143210A (en) | Test task scheduling method and system | |
| CN105955816A (en) | Event scheduling method and device | |
| CN113986484B (en) | Task processing global scheduling method of social software | |
| CN111708799B (en) | Spark task processing method and device, electronic equipment and storage medium | |
| CN113051059B (en) | Multi-GPU task real-time scheduling method and device | |
| CN112114967B (en) | GPU resource reservation method based on service priority |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |