On 12/16/18 11:39 AM, Mike Snitzer wrote: > On Sun, Dec 16 2018 at 11:16am -0500, > Christoph Hellwig <hch@xxxxxx> wrote: > >> On Sun, Dec 16, 2018 at 10:25:16AM +0800, Ming Lei wrote: >>> This patch sets map->nr_queues as zero explictly if there is zero >>> queues for such queue type, then blk_mq_map_swqueue() can become >>> more robust to deal with shared mappings. >> >> This looks a lot more clumsy than what we had before, can you explain >> what additional robustnes it buys us? > > It enables nvme IO to complete on my testbed with for-4.21/block > changes, this NUMA layout is what triggered Ming's work: > > # numactl --hardware > available: 2 nodes (0-1) > node 0 cpus: 0 2 4 6 8 10 12 14 > node 0 size: 128605 MB > node 0 free: 128092 MB > node 1 cpus: 1 3 5 7 9 11 13 15 > node 1 size: 128997 MB > node 1 free: 128529 MB > node distances: > node 0 1 > 0: 10 21 > 1: 21 10 > > Without the aggregate changes from this patchset (1-3 anyway) I get IO > hangs in blkdev_fsync(). Still puzzled. I'm not against the change, but the commit message has NOTHING in the way of justification. "Make X more robust" doesn't mean anything. Your followup brings no extra info to the table in terms of what the bug is here. What exact bug is it fixing? Why is fsync currently hanging? -- Jens Axboe
