5 ms·
Is there any hardware accelerator / co processor / for the PC that will read a file into RAM autonomously mainframish and notify the OS when the file is fully l
by ThinkBeat 4y ago
Is there any hardware accelerator / co processor / for the PC
that will read a file into RAM autonomously mainframish and notify
the OS when the file is fully loaded into memory?
(bypassing the CPU entirely)
Leaving the CPU to bother with other things during that time.
- jbverschoor 4y agoIsn't this what a DMA controller does?
- imtringued 4y agoThat is how I/O works already. The problem is dealing with an asynchronous filesystem API provided by the kernel.
- pca006132 4y agoYou mean DMA?
- jeroenhd 4y agoDo we need a coprocessor for that? Any protocol using DMA already does exactly this through interrupts or other message passing systems. DMA capable controllers are everywhere, I don't think you'll find any storage controllers in your modern computer that don't do this. Of course DMA only operates on byte ranges and not on files, but adding file system parsers to drives and disk controllers sounds like a way to introduce awful bugs and corruption. Assuming the OS keeps the necessary file system structures cached in RAM, plain old DMA should be good enough here.
- wtallis 4y ago> Of course DMA only operates on byte ranges and not on files, but adding file system parsers to drives and disk controllers sounds like a way to introduce awful bugs and corruption. There's an interesting intermediate solution in the form of SSDs that provide a key-value interface instead of a linear block device. That gives the SSD more explicit knowledge about which chunks of data should be kept contiguous and can be expected to have the same lifetime.
- bogomipz 4y ago>"Any protocol using DMA already does exactly this through interrupts or other message passing systems." Interesting, I'm only familiar with the classic interrupts approach. What are some of the other common message passing systems used in DMA?
- wtallis 4y agoNVMe has memory-mapped doorbell registers associated with each submission or completion queue, which are ring buffers typically allocated in host RAM and accessed by the SSD using DMA. Generating interrupts when a new entry is posted to a completion queue is optional. The host system can instead simply poll the completion queue to check whether any new IO operations have been completed. Depending on how busy the drive is vs how busy the CPU is, forgoing interrupts in favor of polling may reduce latency (fewer context switches when handling a new completion), but can also burn a lot of CPU time.
- bogomipz 4y agoThis is really interesting. I wasn't aware that interrupts were handled differently on NVMe disks. The falling back to polling during busy times is similar to the way network device drivers do NAPI then?
- wtallis 4y agoPolling is optional. The Linux driver defaults to using interrupts only, but the nvme driver can be passed an option to allocate one or more queues with interrupts disabled to be used for polled IO. (You can also configure it to use separate queues for reads and writes, instead of just trying to allocate one queue per CPU core.)
- 323 4y agoThis is already how stuff works. There are even OS APIs for this - DirectStorage on Windows.