i/o调度_节省工作的I / O调度程序与不节省工作的I / O调度程序有什么区别？-CSDN博客

i/o调度

What is the difference between work conserving I/O scheduler and non-work conserving I/O scheduler?

节省工作的I / O调度程序与不节省工作的I / O调度程序有什么区别？

In a work-conserving mode, the scheduler must choose one of the pending requests, if any, to dispatch, even if the pending requests are far away from the current disk head position. The rationale for non-work-conserving schedulers, such as the anticipatory scheduler (AS) and Completely Fair Queuing (CFQ), is that a request that is soon to arrive might be much closer to the disk head than the currently pending requests, in which case it may be worthwhile to wait for the future request.

在工作保存模式下，即使未决请求距离当前磁盘头位置很远，调度程序也必须选择其中一个要分发的未决请求。对于非节省工作时间的调度程序（例如，预期调度程序（AS）和完全公平队列（CFQ））的基本原理是，即将到达的请求可能比当前待处理的请求更接近磁盘头。在这种情况下，值得等待将来的请求。

In my point view, non-work conserving keeps the locality of synchronous I/O requests so that the system performance will be improved.

以我的观点，非工作保留可保持同步I / O请求的局部性，从而提高系统性能。

Reference: https://www.usenix.org/legacy/event/fast11/tech/full_papers/Xu.pdf

参考： https : //www.usenix.org/legacy/event/fast11/tech/full_papers/Xu.pdf

Answered by harryxiyou.

由harryxiyou回答。

If there is only one process with intensive I/O requests, we ever noticed that the deadline scheduling algorithm can almost double the I/O throughput from CFQ. With CFQ, it is likely the process’ threads may be waiting for I/O, the I/O scheduler is waiting for requests closer to the disk head while there won’t be as the waiting threads are the only threads having I/O requests. The waiting here wastes time actually.

如果只有一个进程具有大量I / O请求，那么我们曾经注意到，截止期限调度算法几乎可以使CFQ的I / O吞吐量增加一倍。使用CFQ，进程的线程可能正在等待I / O，I / O调度程序正在等待更靠近磁盘头的请求，而不会，因为等待线程是唯一具有I / O的线程要求。这里的等待实际上浪费时间。

Thank you for your comments.

谢谢您的意见。

I think it depends on particular workloads but, in general, consecutive synchronous I/O requests from the same task will have locality feature. In your case, you need to describe your workload clearly so that I can understand why. Anyway, any solution/mechanism has its limitations.

我认为这取决于特定的工作负载，但通常，来自同一任务的连续同步I / O请求将具有局域性。对于您的情况，您需要清楚地描述您的工作量，以便我理解原因。无论如何，任何解决方案/机制都有其局限性。

Yes, it depends on the workloads. A scheduler may work well for one case while work badly for another.

是的，这取决于工作量。调度程序可能适合一种情况，而不适用于另一种情况。

For the case I experienced, it is roughly as follows. A dir contains many (100K+) files of 1MB~5MB. The process first A) reads around 10s-100 files into memory in parallel by around 4-10 threads each time and then B) processes them. The process repeats (A->B) until all files are processed.

对于我经历的情况，大致如下。目录包含许多（100K +）1MB〜5MB的文件。进程首先A）每次大约4-10个线程并行地将大约10s-100个文件读入内存，然后B）处理它们。重复该过程（A-> B），直到处理完所有文件。

The filesystem is an ext4 and it is on top of a RAID5 disk array. Filesystem type may matter too here as the blocks layout matters. But there was no chance to test more FSes, such as XFS.

文件系统是ext4，位于RAID5磁盘阵列的顶部。文件系统类型在这里也可能很重要，因为块布局很重要。但是没有机会测试更多的FS，例如XFS。

For your specific workload, I guess the performance for AS might be affected by following factors.

对于您的特定工作负载，我认为AS的性能可能会受到以下因素的影响。

1, For each process, it might read files which are not stored consecutively on HDD so that AS will be invalid and have a bad impact.

1，对于每个进程，它可能会读取未连续存储在HDD上的文件，从而使AS无效并产生不良影响。

2, It also depends on prefeching mechanisms of OS and hardware.

2，它还取决于操作系统和硬件的预取机制。

3, Another factor may depends on how these threads work since one may be blocked after each read so that AS will be invalid and have bad impact.

3，另一个因素可能取决于这些线程的工作方式，因为每次读取后可能会阻塞一个线程，从而使AS无效并产生不良影响。

If we want to learn the detail reasons, we have to think about this problem from the system stack (application <-> OS <-> Hardware) angle. If it is for virtualized systems, things are changed due to double scheduling, VM consolidation, and device virtualization problems.

如果要了解详细的原因，我们必须从系统堆栈（应用程序<-> OS <->硬件）的角度考虑这个问题。如果是用于虚拟化系统，则由于双重调度，VM整合和设备虚拟化问题，情况将发生变化。

3 is possibly the most affecting factor for the workloads. As the system has only one process doing intensive I/O and it is natural for programs to be implemented to wait on I/O.

3可能是对工作负载影响最大的因素。由于系统只有一个进程执行大量I / O，因此很自然地要实现程序以等待I / O。

Even though you have one process which creates multiple threads in user space but for Linux Kernel, these threads in kernel will be regarded different threads/tasks (gid is the same). That’s why 1 is also one possible reason.

即使您有一个在用户空间中创建多个线程的进程，但对于Linux内核，内核中的这些线程将被视为不同的线程/任务（gid相同）。这就是为什么1也是可能的原因之一。

Agreed. The file writing went through several levels of system components (Windows programs write the files through Samba on Linux through ext4 through a RAID5 card to a disk array with 10+ disks) and the files blocks may be very likely non-consecutive.

同意文件写入经历了多个级别的系统组件（Windows程序通过Linux上的Samba，通过ext4，通过RAID5卡通过ext4将文件写入具有10个以上磁盘的磁盘阵列），并且文件块很可能是非连续的。

Yes, exactly. From my experience, RAID controller will improve I/O performance very much since I/O requests can be handled in parallel via multiple RAID controller channels. Besides, system stack is much more complex in virtualized systems such as KVM, Xen, etc.

对，就是这样。根据我的经验，RAID控制器将大大提高I / O性能，因为可以通过多个RAID控制器通道并行处理I / O请求。此外，在KVM，Xen等虚拟化系统中，系统堆栈要复杂得多。