[contingencies]

Thanks for the clarification. IIRC you are a co-author of the paper, so perhaps you can answer a follow-up question.

What kind of latency or CPU usage change should a typical modern SSD on an amd64 class multicore processor observe when using the new block layer?

Also correct me if I'm wrong but since Linux aggressively caches already and SSDs are already way faster than older drives for normal (ie. ~random access) loads, plus RAM is cheap and plentiful these days, I am guessing that very few applications will honestly be IO-bound enough to see that benefit.

[mbjorling]

One thread issuing IOs: A reduction of 2x in the IO path latency isn't unusual. The overhead of the code path drops from 5us to around 2us. When there's multiple IO threads, the gain is much higher (to 38x in the 8 socket setup). Thus, the more complex workload, the better performance.

I don't have any up-to-date numbers on CPU usage. When we did the experiments on the mtip drive, it was around 20% less CPU usage when performing roughly the same IOs.

For a typical workstation workload, the SSDs access times are still too high to feel the reduced latency. A typical modern SSD is around 50-100us for an IO access. The win there will be the lesser CPU usage that free up resources for other things to do.

Applications are still bound by the round-trip time of getting IOs. Just because we get more memory, we still have to persist data at intervals to prevent data loss, and everything that can help in decreasing the overhead is a win.

[cbsmith]

There are certainly plenty of contexts where SSD's in general provide limited if any performance wins because disk I/O is largely not involved. However, in cases where SSD's are being used for performance reasons, particularly for random reads, I would expect this would make a fair bit of difference.