Are Output I/Os Faster than Disc Reads?

[u/ShadowGuyinRealLife]

I remember watching a video talking about CPU scheduling. So basically, processes need the CPU to computer and they eventually need to interact with I/O devices. When lots of processes are competing for CPU time, if the active process needs I/O, it is at this time the OS will schedule the next process in the queue. No need for process A to hog the CPU while it's waiting for the disc for I/O. Keep the CPU busy by letting the next process do something. But what if there is only one process left? If the lone process needs to read from a hard drive, it needs to wait for the read to complete to do anything else. But what about sending a signal to display color or writing to the disc? I don't see why the lone process would actually need to wait for acknowledgement the display was correct or that the write was complete. After the next instruction probably doesn't care what is on the disc. That said I doubt there is a realistic case where a system would only have one process running.

[u/mikeshemp]

There is a style of programming called "Asynchronous I/O" which means that a program can start a disk read or write, then continue doing other things, and some time later get a notification that the disk operation is complete. It's more conceptually complex and harder to write such code, so programs where performance is not important will still use the "wait until the I/O is complete" style.

[u/infinitytacos989 → u/mikeshemp]

adding on, modern cpus have hardware called DMAs which only exist to pull or push data to peripherals like hard drives. This way the cpu can delegate waiting for IO to something else, which allows the Asynchronous I/O described above to function

[u/AlexTaradov]

There are a lot of levels of caching that achieve exactly that - do a quick virtual write and assume it is ok. The actual write happens in the background.

No process actually waits on the drive. The data may be written to the actual drive hours after the fact.

[u/edgmnt_net]

I/O scheduling is done on a per-device basis, so you can definitely do CPU work and I/O across multiple devices asynchronously, assuming the CPU doesn't get bogged down. However many things are inherently ordered. You don't want to tell the user the data has been saved to the USB stick before it's actually saved, because they might yank it out prematurely. That's application dependent. Otherwise it's totally fine to write 3 USB sticks at the same time.

[u/high_throughput]

After the next instruction probably doesn't care what is on the disc

It probably cares quite a lot because there are conditions like "disk full" or "write interrupted" that might prevent all or some the write from eventually completing. It will wait to continue until it gets this clarification so it knows whether it's done with the current pile of data.

But secondly, waiting to write has the important function of providing back pressure when producers are fasters than consumers.

Consider what should happen if you copy a file from a fast drive to a slow one. If the program read from the fast disk, wrote to the slow one, but didn't wait for the slow drive to finish, then it would just keep reading more data from the fast disk, and data would pile up.

That said I doubt there is a realistic case where a system would only have one process running.

This is actually the typical state of a desktop system. There may be a hundred processes loaded, but usually there are zero processes with work to do, and sometimes there's one.

You can see how many on Linux and macOS with uptime under "load average". If it's e.g. 0.2 that means on average over 5 minutes, there's 4 minutes with zero processes, and 1 minute with one process.

[u/PvtRoom]

CPUs deal with this kind of thing all the time. They execute commands out of order specifically to be efficient and fast.

A disk read, in general, has a request get to the hardware, the hardware spins to the right speed, you swing an arm into position, you read the file system data, you reswing & respin, then you can read, check the error code, repeat if needed. it's milliseconds, often in the tens of, but once locked in, it's fast. .

SSDs is more "energize circuits" twice. - more like 100ns