Shulou(Shulou.com)06/01 Report--

This article will explain in detail how to improve the overall performance of IO under Linux. The editor thinks it is very practical, so I share it with you as a reference. I hope you can get something after reading this article.

IO scheduling occurs at the IO scheduling layer of the Linux kernel. This level is for the overall IO hierarchy of Linux. From the point of view of read () or write () system calls, the overall IO system of Linux can be divided into seven layers, which are:

VFS layer: virtual file system layer. Because the kernel has to deal with a variety of file systems, and the data structures and related methods implemented by each file system may be different, the kernel abstracts this layer and is specially used to adapt to various file systems. and provide a unified operation interface.

File system layer: different file systems implement their own operation process and provide their own unique characteristics, not to mention the details, you can read the code yourself if you like.

Page cache layer: responsible for true caching of page.

General block layer: since most io operations deal with block devices, Linux provides a block device operation abstraction layer similar to the vfs layer. The lower layer docks various block devices with different attributes and provides a unified Block IO request standard for the upper layer.

IO scheduling layer: because the vast majority of block devices are devices such as disks, it is necessary to set up different scheduling algorithms and queues according to the characteristics of these devices and different applications. In order to improve the disk reading and writing efficiency in different application environments, this is where the famous Linux elevator works. Various scheduling methods for mechanical hard disk are realized here.

Block device driver layer: the driver layer provides relatively advanced equipment operation interface, which is often in C language, while the lower layer docks the operation methods and specifications of the equipment itself.

Block device layer: this layer is the specific physical device, defining a variety of true device operation methods and specifications.

There is a sorted out [Linux IO structure diagram], which is very classic, and a picture is worth a thousand words:

What we are going to study today is mainly in the IO scheduling layer.

The core problem it wants to solve is how to improve the overall performance of the block device IO? This layer is also mainly designed for the structure of mechanical hard disk.

As we all know, the storage medium of a mechanical hard disk is a disk, and the head moves on the disk for track addressing, which behaves like playing a record.

The characteristic of this structure is that the throughput of sequential access is high, but once there is random access to the disk, then a lot of time will be wasted on the movement of the magnetic head, which will lead to a longer response time of each IO and greatly reduce the response speed of IO.

The operation of the magnetic head seeking on the disk is similar to elevator dispatching. In fact, in the very beginning, Linux named this algorithm the Linux elevator algorithm, namely:

If the data requests of the relevant tracks passing sequentially can be processed "incidentally" in the process of seeking, then the throughput of the overall IO can be improved with relatively little impact on the response speed.

This is why we design the IO scheduling algorithm.

Currently, three algorithms / modes are turned on by default in the kernel: noop,cfq and deadline. Strictly speaking, it should be two kinds:

Because * is called noop, which is a null operation scheduling algorithm, that is, there is no scheduling operation, and io requests are not sorted, only a fifo queue merged by appropriate io.

Currently, the default scheduling algorithm in the kernel should be cfq, which is called fully fair queue scheduling. This scheduler, as its name suggests, attempts to provide a completely fair IO operating environment for all processes.

Please remember this word, cfq, completely fair queue scheduling, otherwise you won't be able to read the following.

Cfq creates a synchronous IO scheduling queue for each process, and allocates IO resources by default with a time slice and a limited number of requests to ensure that the IO resource consumption of each process is fair. Cfq also implements priority scheduling for the process level, which we will explain in detail later.

The way to view and modify the IO scheduling algorithm is:

Cfq is not only a good choice of IO scheduling algorithm for general-purpose servers, but also a good choice for desktop users.

However, it is not very suitable for many scenarios where the IO pressure is high, especially when the IO pressure is concentrated on some processes.

Because of this scenario, we need to satisfy the IO response speed of one or more processes, rather than let all processes use IO fairly, such as database applications.

Deadline scheduling (deadline scheduling) is the solution that is more suitable for the above scenarios. Deadline implements four queues:

Two of them handle normal read and write respectively, sorted by sector number, and merge normal io to improve throughput. Because IO requests may be concentrated in some disk locations, this will cause new requests to be merged all the time, and io requests from other disk locations may starve to death.

The other two queues that handle timeout read and write are sorted by request creation time, and if there are timed-out requests, they are put into these two queues. The scheduling algorithm ensures that requests in queues that time-out (deadline time is reached) will be processed first to prevent requests from starving to death.

Not long ago, the kernel came with four algorithms by default, and there was another algorithm called as (Anticipatory scheduler), a predictive scheduling algorithm. A high-end name, so that I once thought that the Linux kernel can tell fortune.

It is found that it is nothing more than a short time before io scheduling based on deadline algorithm, and if there are io requests that can be merged during this period, it can be merged to improve the data throughput of deadline scheduling in the case of sequential read and write.

In fact, this is not a prediction at all. I think it would be better to call it the Universiade scheduling algorithm. Of course, this strategy works well in some specific scenarios.

But in most scenarios, this scheduling not only does not improve throughput, but also reduces response speed, so the kernel simply removes it from the default configuration. After all, the purpose of Linux is practical, and we no longer waste too much breath on this scheduling algorithm.

1. Cfq: fully fair queue scheduling

Cfq is the IO scheduling queue selected by default by the kernel, and it is a good choice for desktop application scenarios as well as most common application scenarios.

How to implement a so-called fully fair queue (Completely Fair Queueing)?

First of all, we have to understand that the so-called fairness is fair to whom? From the operating system point of view, the main body of the operation behavior is the process, so the fairness here is for each process, we should try to make the process can fairly occupy IO resources.

So how to make the process take up IO resources fairly? We need to understand what IO resources are first. When we measure an IO resource, we generally prefer to use two units, one is the data read and write bandwidth, and the other is the data read and write IOPS.

Bandwidth is the amount of data read and written in terms of time, for example, 100Mbyte/s. IOPS is the number of reads and writes in time. The performance of the two units may be different in different read-write contexts, but it is certain that if either of the two units reaches the performance limit, it will become a bottleneck for IO.

Considering the structure of mechanical hard disk, if read and write sequentially, then IO can achieve larger bandwidth through less IOPS, because a lot of IO can be merged, and data reading efficiency can be accelerated by pre-reading.

When the performance of IO is biased towards random read and write, then the IOPS becomes larger, the possibility of merging of IO requests decreases, and the lower the bandwidth performance is when there is less data per io request.

From this we can understand that there are two main forms of IO resources for a process: the number of IO requests submitted by the process per unit time and the IO bandwidth occupied by the process.

In fact, either way, it is closely related to the length of IO processing time allocated by the process.

Sometimes services can take up more bandwidth with less IOPS, while others may take up less bandwidth with larger IOPS, so it is relatively fair to schedule the time that processes take up IO.

That is, I don't care if you have a high IOPS or a high bandwidth consumption, we'll switch to another process when it comes time. Do what you like.

Therefore, cfq is an attempt to allocate time slices used by equivalent block devices to all processes. Within the time slice, the process can submit the resulting IO request to the block device for processing. When the time slice ends, the process's request will be placed in its own queue and wait for processing when it is scheduled next time. This is the basic principle of cfq.

Of course, in real life, there can be no real "fairness". In common application scenarios, we are willing to artificially assign priority to the IO occupancy of a process, just like the concept of prioritizing the CPU occupancy of a process.

Therefore, in addition to fair queue scheduling for time slices, cfq provides priority support. Each process can set an IO priority, and cfq will use this priority as an important reference factor when scheduling.

Priority is first divided into three categories: RT, BE and IDLE, which are real-time (Real Time), * * effects (Best Try) and idle (Idle), respectively. Different policies are used to deal with IO,cfq in each category. In addition, in the RT and BE categories, eight more sub-priorities are assigned to implement more detailed QOS requirements, while IDLE has only one sub-priority.

In addition, we all know that the kernel defaults to buffer/cache all reads and writes to storage, in which case cfq cannot tell which process the currently processed request is from.

Cfq can tell which process the IO request came from only if the process uses synchronous (sync read or sync wirte) or direct IO (Direct IO) to read and write.

So, in addition to the IO queues implemented for each process, a common queue is implemented to handle asynchronous requests.

The current kernel has implemented cgroup resource isolation for IO resources, so on the basis of the above architecture, cfq has also implemented scheduling support for cgroup. For a description of cgroup's blkio capabilities, see my previous article, Cgroup-Linux's IO resource isolation.

Generally speaking, cfq uses a series of data structures to support all the above complex functions, and you can see its related implementation through the source code. The file is in the block/cfq-iosched.c in the source code directory.

1.1 cfq design principles

Here, we give a brief description of the overall data structure: first, cfq maintains the entire scheduler process through a data structure called cfq_data. In a cfq that supports cgroup functionality, all processes are divided into several contral group for management.

Each cgroup has a cfq_group structure described in cfq, and all cgroup are put into a red-black tree as a scheduling object, and sorted by vdisktime as key.

Vdisktime records the io time occupied by the current cgroup. Every time the cgroup is scheduled, the cgroup with the least current vdisktime time is always selected through the red-black tree to ensure that the occupation of IO resources between all cgroups is "fair".

Of course, we know that cgroup can allocate resources to blkio in proportion, and its principle is that the cgroup time occupied by vdisktime with a large allocation ratio increases slowly, while the vdisktime time with a small allocation ratio increases faster, which is proportional to the allocation ratio.

In this way, the proportion of IO allocated by different cgroup is different, and it is still "fair" from the point of view of cfq.

After selecting the cgroup (cfq_group) to be processed, the scheduler needs to make a decision to choose the next service_tree.

Service_tree this data structure corresponds to a series of red-black trees, the main purpose is to achieve request priority classification, that is, RT, BE, IDLE classification. Each cfq_group maintains seven service_trees, which is defined as follows:

Service_tree_idle is the red-black tree used to queue requests of type IDLE.

In the above two-dimensional array, the first dimension implements an array for RT and BE respectively, and each array maintains three red-black trees corresponding to three different subtypes of requests: SYNC, SYNC_NOIDLE and ASYNC.

We can think of SYNC as equivalent to SYNC_IDLE and corresponding to SYNC_NOIDLE. Idling is a mechanism added by cfq in order to merge continuous IO requests as much as possible to improve throughput, which can be understood as an "idle" waiting mechanism.

Idling means that when a queue finishes processing a request, it waits for a short period of time before scheduling occurs. If the next request comes, it can reduce head addressing and continue to process sequential IO requests.

In order to achieve this function, cfq implements the SYNC queue in the service_tree data structure. If the request is a synchronous sequential request, join the service tree. If the request is a synchronous random request, join the SYNC_NOIDLE queue to determine whether the next request is a sequential request.

All asynchronous write requests will be queued to ASYNC's service tree, and there is no idle wait mechanism for this queue.

In addition, cfq also makes special adjustments to hard drives such as SSD. When cfq discovers that the storage device is a ssd hard disk with a deeper queue, all idling for individual queues will not take effect, and all IO requests will be queued to SYNC_NOIDLE the service tree.

Each service tree corresponds to several cfq_queue queues, and each cfq_queue queue corresponds to a process, which we will explain in more detail later.

Cfq_group also maintains an asynchronous IO request queue common to all processes within cgroup, which is structured as follows:

Asynchronous requests are also divided into three categories: RT, BE and IDLE, each of which is queued with a cfq_queue.

BE and RT also implement priority support, with each type having as many priorities as IOPRIO_BE_NR, with a value of 8 and an array subscript of 0-7.

The kernel code version we are currently analyzing is Linux 4.4.We can see that from the perspective of cfq, we can already implement the cgroup support of asynchronous IO. We need to define the meaning of the so-called asynchronous IO here. It only represents the synchronization of data from the buffer/cache in memory to the IO request of the hard disk, rather than aio (man 7 aio) or linux's native asynchronous io and libaio mechanism. In fact, these so-called "asynchronous" IO mechanisms They are all implemented synchronously in the kernel (in essence, von Neumann computers have no real "asynchronous" mechanism).

As we have explained above, since processes normally write data to buffer/cache first, this asynchronous IO is handled uniformly by the async request queue in cfq_group.

So why implement an ASYNC type in the above service_tree?

This is, of course, in preparation for supporting process-differentiated asynchronous IO and making it "completely fair".

In fact, in the blkio system of cgroup v2, the kernel already supports cgroup speed limit support for buffer IO, and the above types that may be easily confused are all type tags that need to be used in the new system.

The new system is more complex and more powerful, but don't worry, the formal cgroup v2 system will be officially available when Linux 4.5 is released.

Let's continue the process of selecting service_tree. The selection of the three priority types of service_tree is based on the priority of the type, RT priority, BE, and IDLE***. That is to say, if you have it in RT, you will always deal with RT,RT and then deal with BE.

Each service_tree corresponds to a red-black tree whose elements are queued for cfq_queue, and each cfq_queue is the request queue that the kernel creates for the process (thread).

Each cfq_queue maintains a variable of rb_key, which is actually the IO service time (service time) of the queue.

Here or through the red-black tree to find the cfq_queue with the shortest service time time to serve, in order to ensure "complete fairness".

Once the cfq_queue is selected, it's time to start processing the IO requests in this queue. The scheduling method here is basically similar to that of deadline.

Cfq_queue queues each request that enters the queue twice, one in the fifo and the other in the red-black tree that acts as a key in the order of the access sector.

By default, the request is taken from the red-black tree for processing. When the delay time of the request reaches deadline, the one with the longest waiting time is taken from the red-black tree for processing to ensure that the request does not starve to death.

This is the entire cfq scheduling process, of course, there are many details unexplained, such as merge processing and sequential processing, and so on.

1.2Parametric adjustment of cfq

Understanding the whole scheduling process helps us to decide how to adjust the relevant parameters of cfq. All cfq tunables can be found in the / sys/class/block/sda/queue/iosched/ directory, of course, on your system, replace sda with the appropriate disk name. Let's take a look at what we have:

Some of these parameters are related to the seek mode of the head of the mechanical hard disk. If you don't understand it, please add the relevant knowledge first:

Back_seek_max: the range in which the head can be addressed backward. The default value is 16m.

Back_seek_penalty: penalty factor for backward addressing. This value is compared to forward addressing.

The above two are set to prevent the slow addressing caused by the jitter of the head seek. The basic idea is that when an io request arrives, cfq estimates its head seek cost based on its addressing location.

Set a * * value back_seek_max, and if the sector number accessed by the request is behind the head, as long as the addressing range does not exceed this value, cfq will process it like a forward addressing request.

Then set a coefficient back_seek_penalty to evaluate the cost. When the distance of backward addressing relative to the forward addressing of the head is 1 1/back_seek_penalty, cfq believes that the cost of the two requests is the same.

These two parameters are actually the conditions for cfq to judge the merging processing of requests. All requests that combine this condition will be merged together as far as possible when this request is processed.

Fifo_expire_async: sets the timeout for asynchronous requests.

Synchronous requests and asynchronous requests are processed by different queues. Cfq usually gives priority to synchronous requests and then asynchronous requests, unless asynchronous requests meet the conditions of the above merge processing.

When the queue of the process is scheduled, cfq will first check whether there is an asynchronous request timeout, that is, exceeding the limit of the fifo_expire_async parameter. If so, a timeout request is sent first, and the rest of the requests are still processed according to the priority and sector number size.

Fifo_expire_sync: this parameter is similar to the one above, except that it is used to set the timeout for synchronization requests.

Slice_idle: the parameter sets a wait time. This allows cfq to wait for a period of time while switching between cfq_queue or service tree in order to improve the throughput of mechanical hard drives.

In general, IO requests from the same cfq_queue or service tree have better addressing locality, so this reduces the number of disk addresses. This value defaults to non-zero on mechanical hard drives.

Of course, setting this value to non-zero on solid-state drives or hard RAID devices reduces storage efficiency, because solid-state drives don't have the concept of head addressing, so you should set it to 0 on such devices to turn off this feature.

Group_idle: this parameter is similar to the previous one, except that cfq waits for a period of time when it wants to switch cfq_group.

In the cgroup scenario, if we follow the slice_idle approach, idling waits may occur when each process in the cgroup group switches over the cfq_queue.

In this way, if the process has requests to process all the time, other processes in the same group may not be able to schedule until the quota for this cgroup is exhausted. This will cause other processes in the same group to starve to death and create IO performance bottlenecks.

In this case, we can put slice_idle = 0 and group_idle = 8. In this way, idling waits are done in cgroup units, not cfq_queue processes, in order to prevent the above problems.

Low_latency: this is the switch used to turn on or off the low latency (low latency) mode of cfq.

When this switch is turned on, cfq will recalculate the fragmentation time (slice time) of each process according to the parameter settings of target_latency.

This will benefit fairness to throughput (fair allocation of time slices by default).

Turning off this parameter (set to 0) ignores the value of target_latency. This will enable the processes in the system to allocate IO resources in a time-slice manner. This switch is on by default.

We already know that cfq is designed to have the concept of "idling" in order to merge as many consecutive read and write operations as possible, reducing the addressing of heads to increase throughput.

If a process always reads and writes sequentially very quickly, it will slow down the response speed of other processes that need to deal with IO because of the high idle waiting rate of cfq. If another process that needs to be scheduled does not issue a large number of sequential IO behaviors, the performance of IO throughput of different processes in the system will be very uneven.

For example, when there are many dirty pages to be written back in the cache of the system memory, and the desktop needs to open a browser for operation, the background behavior of writing back dirty pages is likely to cause a large amount of idle time, resulting in a small amount of IO of the browser waiting, making users feel that the response speed of the browser becomes slower.

This low_latency is mainly an option to optimize this situation. When it is turned on, the system limits the processes that consume a large amount of IO throughput due to * idling according to the configuration of target_latency, so as to achieve a relative balance of throughput occupied by different processes'IO. This switch is suitable to be turned on in scenarios similar to desktop applications.

Target_latency: when the value of low_latency is on, cfq will recalculate the IO time slice length allocated by each process based on this value.

Quantum: this parameter is used to set how many IO requests are processed from cfq_queue at a time. IO requests that exceed this number will not be processed during a queue processing event cycle. This parameter is valid only for synchronized requests.

Slice_sync: when a cfq_queue queue is scheduled for processing, the total processing time it can be allocated is specified as a calculation parameter by this value. The formula is time_slice = slice_sync + (slice_sync/5 * (4-prio)). This parameter is valid for synchronous requests.

Slice_async: this value is similar to the previous one, except that it is valid for asynchronous requests.

Slice_async_rq: this parameter is used to limit the maximum number of asynchronous requests a queue can handle within a slice time frame. The number of requests processed is also related to the io priority set by the relevant process.

1.3The IOPS mode of cfq

We already know that by default, cfq is a priority scheduling supported by time slices to ensure fair usage of IO resources.

High-priority processes will get more time slices, while low-priority processes will get smaller time slices.

When our storage is a high-speed device that supports NCQ (native instruction queue), we can allow it to handle multiple requests from multiple cfq queues in order to improve NCQ utilization.

At this point, it is inappropriate to use the time slice allocation method to allocate resources, because based on the time slice allocation, there is only one request queue that can be processed at most at a time.

At this point, we need to switch from cfq mode to IOPS mode. The switching method is very simple, which is to use slice_idle=0. The kernel automatically detects whether your storage device supports NCQ, and if so, cfq automatically switches to IOPS mode.

In addition, in the default priority-based time slice mode, we can use the ionice command to adjust the IO priority of the process. The default IO priority assigned by the process is calculated based on the nice value of the process. The calculation method can be seen in man ionice, and there is no more nonsense here.

2. Deadline: deadline scheduling

The deadline scheduling algorithm is much simpler than cfq.

Its design objectives are:

While ensuring that the requests are accessed in the order of the device sectors, while taking into account that other requests will not be starved to death, they should be scheduled before a deadline.

We know that the seek of the magnetic head to the disk can be accessed sequentially and randomly. Because of the delay time of the seek, the throughput of IO is larger in sequential access and smaller in random access.

If we want to optimize the throughput of a mechanical hard disk, we can have the scheduler sort the IO requests accessed in as composite order as possible, and then send the requests to the hard disk in that order, which will increase the throughput of IO.

But there is another problem with this, that is, if a request appears at this time, the track it wants to access is far away from the track where the current head is located, and the application requests are largely concentrated near the current track.

As a result, a large number of requests will always be merged and queue-jumped, and the request to access the more distant tracks will starve to death because it has not been dispatched.

Deadline is such a scheduler, which can make remote requests scheduled within a period of time without being starved to death while ensuring IO*** throughput.

2.1 deadline Design principles

To achieve this goal, the deadline scheduler implements two types of queues, one of which is responsible for sorting requests by access sector. This queue uses a red-black tree organization called sort_list. The other sorts the requested access time. Use linked list organization, called fifo_list.

Because of the obvious difference in the processing of read and write requests, in each type of queue, there are two queues according to the read and write type of the request, that is, the deadline scheduler actually has four queues:

Read queues sorted by sector access order

Write queues sorted by sector access order

Read queue sorted by request time

Write queue sorted by request time.

The reason why deadline separates the read and write queues is to achieve a higher priority for read operations than write operations.

From the application point of view, the read operation is generally a synchronous behavior, that is, when reading, the program usually has to wait until the data is returned before doing the next step.

While the synchronization requirement of write operation is not obvious, the general program can write the data to the cache, and then the kernel is responsible for synchronizing to storage.

Therefore, the optimization of the read operation can obviously benefit. Of course, under such circumstances, deadline must consider the situation that the write operation will starve to death to ensure that it will not starve to death.

Deadline's queuing is simple: when a new IO request is generated and the necessary merge operation is performed, it will queue sort_list and fifo_list in the deadline scheduler in sector order and request generation time, respectively. And then further join the queue to the corresponding read or write queue according to the type of read and write requested.

The handling of deadline's departure is relatively troublesome:

First determine whether the read queue is empty, if the read queue is not empty and the write queue is not hungry (starved

< writes_starved)则处理读队列，否则处理写队列(第4部)。 进入读队列处理后，首先检查fifo_list中是否有超过最终期限(read_expire)的读请求，如果有则处理该请求以防止被饿死。 如果上一步为假，则处理顺序的读请求以增大吞吐。 如果第1部检查读队列为空或者写队列处于饥饿状态，那么应该处理写队列。其过程和读队列处理类似。 进入写队列处理后，首先检查fifo_list中是否有超过最终期限(write_expire)的写请求，如果有则处理该请求以防止被饿死。 如果上一步为假，则处理顺序的写请求以增大吞吐。 整个处理逻辑就是这样，简单总结其原则就是，读的优先级高于写，达到deadline时间的请求处理高于顺序处理。正常情况下保证顺序读写，保证吞吐量，有饥饿的情况下处理饥饿。 2.2 deadline的参数调整 deadline的可调参数相对较少，包括： read_expire:读请求的超时时间设置，单位为ms。当一个读请求入队deadline的时候，其过期时间将被设置为当前时间+read_expire，并放倒fifo_list中进行排序。 write_expire:写请求的超时时间设置，单位为ms。功能根读请求类似。 fifo_batch:在顺序(sort_list)请求进行处理的时候，deadline将以batch为单位进行处理。 每一个batch处理的请求个数为这个参数所限制的个数。在一个batch处理的过程中，不会产生是否超时的检查，也就不会产生额外的磁盘寻道时间。 这个参数可以用来平衡顺序处理和饥饿时间的矛盾，当饥饿时间需要尽可能的符合预期的时候，我们可以调小这个值，以便尽可能多的检查是否有饥饿产生并及时处理。 增大这个值当然也会增大吞吐量，但是会导致处理饥饿请求的延时变长。 writes_starved:这个值是在上述deadline出队处理***步时做检查用的。用来判断当读队列不为空时，写队列的饥饿程度是否足够高，以时deadline放弃读请求的处理而处理写请求。 当检查存在有写请求的时候，deadline并不会立即对写请求进行处理，而是给相关数据结构中的starved进行累计。 如果这是***次检查到有写请求进行处理，那么这个计数就为1。如果此时writes_starved值为2，则我们认为此时饥饿程度还不足够高，所以继续处理读请求。 只有当starved >

When = writes_starved, deadline goes back to process the write request. It can be considered that this value is used to balance the priority status of deadline processing of read and write requests. The higher this value is, the more lagged the write request is, and the smaller the write request is, the closer the priority of the write request is to the read request.

Front_merges: when a new request is queued, it can be merged if the requested sector is close to the current sector.

There may be two situations for this merger:

Is to merge to the current location

It's a forward merger.

In some scenarios, forward merging is not necessary, so we can turn off forward merging with this parameter. The default deadline supports forward merge and is set to 0 to turn off.

3. Noop scheduler

The noop scheduler is the simplest scheduler. It is essentially a fifo queue implemented by a linked list and simply merges requests. The scheduler itself does not provide any suspicious configuration parameters.

4. Application scenario selection of various schedulers.

According to the analysis of the above io scheduling algorithms, we should be able to have some general ideas about the use scenarios of various scheduling algorithms.

In principle, cfq is a general scheduling algorithm, which takes the process as the starting point to ensure that everyone is as fair as possible.

Deadline is a scheduling algorithm based on improving the throughput of mechanical hard disk, which ensures scheduling when io requests reach the deadline as far as possible. It is very suitable for businesses with relatively single business and heavy IO pressure, such as databases.

And noop? In fact, if we extend our thinking to SSDs, you will find that both cfq and deadline are queue algorithm adjustments for the structure of mechanical hard drives, which are completely meaningless for SSDs.

For solid state drives, the more complex the IO scheduling algorithm, the more additional logic to deal with and the less efficient it will be.

Therefore, the use of noop in SSDs is * *, followed by deadline, while cfq is undoubtedly efficient because of its complexity.

This is the end of the article on "how to improve the overall performance of IO under Linux". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, please share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.