On 08/27/2018 03:00 PM, Ming Lei wrote: > On Mon, Aug 27, 2018 at 01:56:39PM +0800, jianchao.wang wrote: >> Hi Ming >> >> Currently, blk_mq_update_dispatch_busy is hooked in blk_mq_dispatch_rq_list >> and __blk_mq_issue_directly. blk_mq_update_dispatch_busy could be invoked on multiple >> cpus concurrently. But there is not any protection on the hctx->dispatch_busy. We cannot >> ensure the update on the dispatch_busy atomically. > > The update itself is atomic given type of this variable is 'unsigned int'. The blk_mq_update_dispatch_busy doesn't just write on a unsigned int variable, but read, calculate and write. The whole operation is not atomic. > >> >> >> Look at the test result after applied the debug patch below: >> >> fio-1761 [000] .... 227.246251: blk_mq_update_dispatch_busy.part.50: old 0 ewma 2 cur 2 >> fio-1766 [004] .... 227.246252: blk_mq_update_dispatch_busy.part.50: old 2 ewma 1 cur 1 >> fio-1755 [000] .... 227.246366: blk_mq_update_dispatch_busy.part.50: old 1 ewma 0 cur 0 >> fio-1754 [003] .... 227.266050: blk_mq_update_dispatch_busy.part.50: old 2 ewma 3 cur 3 >> fio-1763 [007] .... 227.266050: blk_mq_update_dispatch_busy.part.50: old 0 ewma 2 cur 2 >> fio-1761 [000] .... 227.266051: blk_mq_update_dispatch_busy.part.50: old 3 ewma 2 cur 2 >> fio-1766 [004] .... 227.266051: blk_mq_update_dispatch_busy.part.50: old 3 ewma 2 cur 2 >> fio-1760 [005] .... 227.266165: blk_mq_update_dispatch_busy.part.50: old 2 ewma 1 cur 1 >> ... >> >> Is it expected ? > > Yes, it won't be a issue in reality given hctx->dispatch_busy is used as > a hint, and it often works as expected and hctx->dispatch_busy is convergent > finally because it is exponential weighted moving average. I just concern the value of dispatch_busy will bounce up and down in small range with high workload on 32 or higher core system due to the cache and non-atomic update > > Thanks, > Ming >
