3 ms·
One of the big innovations of NVMe over SATA was giving us a bunch of separate command queues. It'd be lovely to get some per queue information. I feel like ma
by jauntywundrkind 1y ago
One of the big innovations of NVMe over SATA was giving us a bunch of separate command queues. It'd be lovely to get some per queue information.
I feel like maybe some of this info is already available we just don't commonly look at it: knowing how deep the queue is, how many commands are outstanding at any given moment is probably a decent start. I haven't spent time digging into blk-mq to see what's available, to understand the hardware dispatch queue (how the kernel represents the many hardware queues available) info. https://www.kernel.org/doc/html/v5.16/block/blk-mq.html https://www.kernel.org/doc/html/v5.16/block/blk-mq.html
- adgjlsfhk1 1y agoI think a lot of the problem is that the ssd is fast enough and far enough away that by the time you get a response back it's fairly out of date
- dleary 1y agoThat’s a separate concern. Every command that you issue to the ssd returns a response. It would be nice to have a bunch of performance counters that tell us where the time went with each of the commands we give it. GPUs have this already.
- wmf 1y agoThis was solved in networking by having the device collect a histogram of queue occupancy.
- fh973 1y agoQueues tend to be always full or always empty (see queueing theory). There is no steady state with a half full queue. For NVMe in particular you will have a hard time filling their queues. Your perceived performance is mostly latency, as there is hardly an application that can submit enough concurrent requests.