Please enable JavaScript.

Coggle requires JavaScript to display documents.

NVMe B+ tree Paper (defence (specific to NVMe(libaio), most modern SSD,…

- - - - no transaction assumed, only lock to ensure the consistency for each operation
    - - we need to submit as many ops to IO queue as possible while processing thread is processing
        
        use one thread, pipeline
        
        assume (IO latency/each piece of CPU time) is very large, thus we need deep submission queue
        
        that's why SATA SSD will not utilize this
        
        multithread
        
        use large number of threads
        
        in theory, we need to compare the (number of threads) vs. (IO latency/each piece of CPU time), and take the context switches and CPU consumptions as penalty
        
        use as many threads as the cores
        
        if no context switches, it should have relative similar performance as single thread version
    - - one queue pair
        
        the queue is executing asynchronously
      - multiple queues
        
        as many queue pairs as the cores
        
        large number of queues
        
        proved will impact the performance
- - - - do we need that long queue?
        
        the IO latency is relatively long compare to the final throughput
        
        we have each node to next node transition relatively fast
      - NVMe get very long io queue