Sleep Mode zZ wrote:
RaTTuS wrote:YMMV - also you can change the disk buffer to be deadline instead of CFQ I used to do this when I ran Linux of sdcard on PC's years back ....
I don't think that deadline scheduler would improve performance here. If I understand it correctly, it handles the wite queue differently than CFQ and noop - the difference being in how they do give precedence to different buffered writes. Deadline gives the writes a deadline, CFQ tries to be fair to all processes. I'm not sure if a choice between them they will make any real difference.
The problem is that unlike file writes, file reads can't be buffered and kept waiting, because the process can't go on without getting the io it needs. And if the process can't go on, the user can't go on but must wait until the file read is done. If small file writes is a serious performance bottleneck, then it must be because those slow small writes are blocking reads. Unlike writes, reads can't be put off to wait for a better moment but has to be done as fast as possible for the computer to stay responsive. The ideal system would not write anything unless the read-queue is empty, giving always precedence to reads. The write queue should be big enough to hold many megabytes of writes. If the writes are given a deadline, it should be at least a minute or two not a couple of seconds. And, yes, this will make the system more prone to data loss but I think that in many use cases that would be preferable to a sluggish system.
I read a little about CFQ and deadline I/O schedulers. RaTTuS seems to be right - deadline should be better than CFQ if you have a card with very slow random access writes.
What I found about CFQ is that it makes a distinction between synchronous and asynchronous I/O - and serves the synchronous first. The problem with this is that it depends on the programmers to take the extra step and make an asynchronous request when they haveto write something to the disk. For small writes, I would guess, many programmers would take the synchronous request to be appropriate even when the program is not doing anything time critical after that - maybe only waiting to quit.
Deadline scheduler, on the other hand, makes a distinction between reads and writes - and serves the reads first. That is what I hoped for in my previous post. In addition I hoped that the write queue could be made as long as necessary while keeping the read queue short. The deadline scheduler has settings for 'read_expire' and 'write_expire', defined in millisecond in which a request should be served. The default settings are 500 ms for the reads and 5000 ms for the writes. That 5000 ms could be enough or it could be increased to a minute or two. There is also a setting 'writes_starved' that determines how much the reads will be preferred over the writes. I don't know what is the default value, but making it higher will make the scheduler prefer reads even more. So the deadline scheduler is exactly what I hoped for.
So, if someone has a sd card with very slow random writes, he/she should try if changing the I/O scheduler to deadline helps to keep the system responsive. It is possible to change the I/O scheduler on the fly, without rebooting or logging out. That should make it easy to find out if slow random access writes is the real problem with Linux - or is it the slow read speeds, like I still suspect. Of course, if a program writes to the disk, without making the write request in a separate thread - and freezes its whole GUI while waiting for an answer from the OS - it could behave even worse with the deadline scheduler.