2 ms·

> I'm not sure that's how it works This article [1] contains benchmark results for several SSDs and a good HDD. You can compare sequential read speed in fastes

> I'm not sure that's how it works This article [1] contains benchmark results for several SSDs and a good HDD. You can compare sequential read speed in fastest mode (SEQ1M) and random read speed in slowest mode (RND4K) and see that there is a huge difference for both HDD and SSD on order of 50x (for SSD) and 300x (for HDD). HDD is very slow for random read/write access because it needs to wait until the desired sector will spin underneath the head, one spin takes approximately 10 ms, and on average you need to wait half of that time. > For your HDD to reach that speed in sequential write, the free space should be contiguous. If the file system is smart enough to allocate large chunks of free sectors then the write will be sequential. If there are no large contiguos chunks then maybe you need to defragment your drive using standard Windows tools (don't know if there are similar tools for Linux) otherwise write speed will be very low. > SSDs actually can take advantage of parallelization This doesn't matter when you need to swap pages in because you retrieve one page after other and cannot parallelize this (as pages are swapped in only when they are accessed by the program). But I can agree that buying $30 SSD is probably the cheapest way to speed up an old computer. [1] https://glennsqlperformance.com/2020/12/13/some-quick-comparative-crystaldiskmark-results-in-2020/ https://glennsqlperformance.com/2020/12/13/some-quick-compar...

vladvasiliu 4y ago
Your example is a worst-case scenario, where only one very small write operation happens at a time for a very small size, yet there are a lot of things to write. It would seem that Linux swap uses the block device layer to handle actual I/O for swap. So, I think that if it only needs to write or read one single page at a time, then sure, it will be slow. But if you need to swap out a sizeable quantity of memory (meaning multiple pages), it will need to write or read multiple pages "at a time". Linux also tends to group pages together. Since reading and writing is async [0], as soon as the io operation has been sent, the next page will start to be handled, even if the actual io to disk hasn't finished. So, in practice, it's very likely that there are several IO operations happening at the same time from the drive's point of view. The system is also highly likely to be doing some unrelated I/O, which is why parallelism helps a lot. This is where the SSD will shine, because it will absolutely be able to handle multiple small IOs in parallel [1]. And also where, presumably, queue-ordering in the case of spinning drives can help here, too, by optimizing the order in which the paging operations will occur. I'm not familiar with Windows, but I'd expect things to work somewhat similarly, especially since the swap is backed by an actual file system (but I don't know if the swap files have any properties that make it "special" - though I wouldn't be surprised for that to be the case). --- [0] https://www.kernel.org/doc/gorman/html/understand/understand014.html https://www.kernel.org/doc/gorman/html/understand/understand... look for heading 11.7 [1] See RND4K / Q32T16 in your benchmark, where the factor is only 2.

vladvasiliu 4y ago

Your example is a worst-case scenario, where only one very small write operation happens at a time for a very small size, yet there are a lot of things to write. It would seem that Linux swap uses the block device layer to handle actual I/O for swap. So, I think that if it only needs to write or read one single page at a time, then sure, it will be slow. But if you need to swap out a sizeable quantity of memory (meaning multiple pages), it will need to write or read multiple pages "at a time". Linux also tends to group pages together. Since reading and writing is async [0], as soon as the io operation has been sent, the next page will start to be handled, even if the actual io to disk hasn't finished. So, in practice, it's very likely that there are several IO operations happening at the same time from the drive's point of view. The system is also highly likely to be doing some unrelated I/O, which is why parallelism helps a lot. This is where the SSD will shine, because it will absolutely be able to handle multiple small IOs in parallel [1]. And also where, presumably, queue-ordering in the case of spinning drives can help here, too, by optimizing the order in which the paging operations will occur. I'm not familiar with Windows, but I'd expect things to work somewhat similarly, especially since the swap is backed by an actual file system (but I don't know if the swap files have any properties that make it "special" - though I wouldn't be surprised for that to be the case). --- [0] https://www.kernel.org/doc/gorman/html/understand/understand014.html https://www.kernel.org/doc/gorman/html/understand/understand... look for heading 11.7 [1] See RND4K / Q32T16 in your benchmark, where the factor is only 2.