The creation of the io.latency block I/O controller

Re:The creation of the io.latency block I/O controller by abhinai on Saturday March 30, 2019 @02:41AM (#19528146)

So many algorithms, data structures and patterns in computer sciences were based on the idea that hard disks are slow and their seek times are especially slow. However, the introduction of solid state drives has changed this. There days I have almost no server with an actual disk drive on it.

I wonder how (1) the software has evolved to face this new reality, (2) how much of the old code is still being used and (3) what are the performance penalties we pay for using disk performance characteristic assumptions in code that actually runs on solid state drives?

[ Parent | on HN ]

Re:The creation of the io.latency block I/O controller by thatsaguy on Saturday March 30, 2019 @08:05AM (#19529003)

Incidentally, SSDs also benefit from read and write locality. Although there's no seek penalty, there's still a large benefit from dispatching multiple reads and writes from/to the same cell. You get those for free by trying to minimize "seeks", although the underlying logic behind this optimization is simpler.

[ Parent | on HN ]

Re:The creation of the io.latency block I/O controller by ignoramous on Saturday March 30, 2019 @02:51AM (#19528186)

Well, most distributions choose saner defaults. For instance, RHEL/CentOS/AmazonLinux use noop io-scheduler by default for SSD based machines.

Though, I get your point: for instance, the TCP keep-alive defaults aren't suitable for all kinds of workloads: https://docs.aws.amazon.com/redshift/latest/mgmt/connecting-...

I guess, that's why performance tuning is an art form as it is workload dependant: https://youtu.be/89fYOo1V2pA

[ Parent | on HN ]