- 08 Jul, 2020 1 commit
-
-
Ming Lei authored
Current handling of q->mq_ops->queue_rq result is a bit ugly: - two branches which needs to 'continue' have to check if the dispatch local list is empty, otherwise one bad request may be retrieved via 'rq = list_first_entry(list, struct request, queuelist);' - the branch of 'if (unlikely(ret != BLK_STS_OK))' isn't easy to follow, since it is actually one error branch. Streamline this handling, so the code becomes more readable, meantime potential kernel oops can be avoided in case that the last request in local dispatch list is failed. Fixes: fc17b653 ("blk-mq: switch ->queue_rq return value to blk_status_t") Signed-off-by:
Ming Lei <ming.lei@redhat.com> Reviewed-by:
Johannes Thumshirn <johannes.thumshirn@wdc.com> Cc: Christoph Hellwig <hch@infradead.org> Signed-off-by:
Jens Axboe <axboe@kernel.dk>
-
- 07 Jul, 2020 1 commit
-
-
Christoph Hellwig authored
If blk_mq_submit_bio flushes the plug list, bios for other disks can show up on current->bio_list. As that doesn't involve any stacking of block device it is entirely harmless and we should not warn about this case. Fixes: ff93ea0c ("block: shortcut __submit_bio_noacct for blk-mq drivers") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
- 02 Jul, 2020 2 commits
-
-
Christoph Hellwig authored
bio_alloc_bioset references current->bio_list[1], so we need to initialize it for the blk-mq submission path as well. Fixes: ff93ea0c ("block: shortcut __submit_bio_noacct for blk-mq drivers") Reported-by:
Qian Cai <cai@lca.pw> Reported-by:
Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by:
-
Jens Axboe authored
This reverts commits the following commits: 37f4a24c 723bf178 36a3df5a The last one is the culprit, but we have to go a bit deeper to get this to revert cleanly. There's been a report that this breaks some MMC setups [1], and also causes an issue with swap [2]. Until this can be figured out, revert the offending commits. [1] https://lore.kernel.org/linux-block/57fb09b1-54ba-f3aa-f82c-d709b0e6b281@samsung.com/ [2] https://lore.kernel.org/linux-block/20200702043721.GA1087@lca.pw/Reported-by:
Marek Szyprowski <m.szyprowski@samsung.com> Reported-by:
-
- 01 Jul, 2020 31 commits
-
-
Jens Axboe authored
Since merging the commit identified in Fixes below, we trigger this compile time warning: drivers/md/dm.c: In function ‘__map_bio’: drivers/md/dm.c:1296:24: warning: unused variable ‘md’ [-Wunused-variable] 1296 | struct mapped_device *md = io->md; | ^~ Remove the 'md' variable. Fixes: 5a6c35f9 ("block: remove direct_make_request") Signed-off-by: -
John Garry authored
sbitmap works by maintaining separate bitmaps of set and cleared bits. The set bits are cleared in a batch, to save the burden of continuously locking the "word" map to unset. sbitmap_bitmap_show() only shows the set bits (in "word"), which is not too much use, so mask out the cleared bits. Fixes: ea86ea2c ("sbitmap: ammortize cost of clearing bits") Signed-off-by:
John Garry <john.garry@huawei.com> Signed-off-by:
-
Christoph Hellwig authored
Instead just iterate over the inodes for the block device superblock. Reviewed-by:
-
Christoph Hellwig authored
Reviewed-by:
-
Christoph Hellwig authored
Just use bd_disk->queue instead. Reviewed-by:
-
Christoph Hellwig authored
We can trivially calculate the block size from the inodes i_blkbits variable. Use that instead of keeping two redundant copies of the information in slightly different formats. Reviewed-by:
-
Christoph Hellwig authored
The loop to increase the initial block size doesn't really make any sense, as the AND operation won't match for powers of two if it didn't for the initial block size. Signed-off-by:
-
Christoph Hellwig authored
bd_block_size contains a value that matches the logic block size when opening, so the statement is redundant. Even if it wasn't the dumb assignment would cause a a mismatch with bd_inode->i_blkbits. Reviewed-by:
-
Christoph Hellwig authored
Use the block_size helper instead of open coding it. Also remove the check for a 0 block size, as that can't happen. Reviewed-by:
-
Hongnan Li authored
ktime_to_ns(ktime_get()), which is expensive, does not need to be called if blk_iolatency_enabled() return false in blkcg_iolatency_done_bio(). Postponing ktime_to_ns(ktime_get()) execution reduces the CPU usage when blk_iolatency is disabled. Signed-off-by:
Hongnan Li <hongnan.li@linux.alibaba.com> Signed-off-by:
-
Christoph Hellwig authored
Now that submit_bio_noacct has a decent blk-mq fast path there is no more need for this bypass. Signed-off-by:
-
Christoph Hellwig authored
For blk-mq drivers bios can only be inserted for the same queue. So bypass the complicated sorting logic in __submit_bio_noacct with a blk-mq simpler submission helper. Signed-off-by:
-
Christoph Hellwig authored
Split out a __submit_bio_noacct helper for the actual de-recursion algorithm, and simplify the loop by using a continue when we can't enter the queue for a bio. Signed-off-by:
-
Christoph Hellwig authored
generic_make_request has always been very confusingly misnamed, so rename it to submit_bio_noacct to make it clear that it is submit_bio minus accounting and a few checks. Signed-off-by:
-
Christoph Hellwig authored
The make_request_fn is a little weird in that it sits directly in struct request_queue instead of an operation vector. Replace it with a block_device_operations method called submit_bio (which describes much better what it does). Also remove the request_queue argument to it, as the queue can be derived pretty trivially from the bio. Signed-off-by:
-
Christoph Hellwig authored
The variable is only used once, so just open code the bio_sector() there. Signed-off-by:
-
Christoph Hellwig authored
All registers disks must have a valid queue pointer, so don't bother to log a warning for that case. Signed-off-by:
-
Christoph Hellwig authored
The "generic_make_request: " prefix has no value, and will soon become stale. Signed-off-by:
-
Christoph Hellwig authored
The queue can be trivially derived from the bio, so pass one less argument. Signed-off-by:
-
Christoph Hellwig authored
All bios can get remapped if submitted to partitions. No need to comment on that. Signed-off-by:
-
Christoph Hellwig authored
Instead of setting up the queuedata as well just use one private data field. Signed-off-by:
-
Christoph Hellwig authored
Nothing in bcache actually uses the ->queuedata field. Signed-off-by:
-
Christoph Hellwig authored
Instead of setting up the queuedata as well just use one private data field. Signed-off-by:
-
Christoph Hellwig authored
Instead of setting up the queuedata as well just use one private data field. Signed-off-by:
-
Christoph Hellwig authored
Instead of setting up the queuedata as well just use one private data field. Signed-off-by:
-
Christoph Hellwig authored
Instead of setting up the queuedata as well just use one private data field. Signed-off-by:
-
Christoph Hellwig authored
Instead of setting up the queuedata as well just use one private data field. Signed-off-by:
-
Christoph Hellwig authored
Instead of setting up the queuedata as well just use one private data field. Signed-off-by:
-
Christoph Hellwig authored
Instead of setting up the queuedata as well just use one private data field. Signed-off-by:
-
Christoph Hellwig authored
Instead of setting up the queuedata as well just use one private data field. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Acked-by:
-
Hou Tao authored
Just use rq directly, the usage of list_entry_rq() doesn't make any sense. Signed-off-by:
Hou Tao <houtao1@huawei.com> Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
-
- 30 Jun, 2020 5 commits
-
-
Colin Ian King authored
There is a statement that is indented one level too deeply, fix it by removing a tab. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Ming Lei authored
Move .nr_active update and request assignment into blk_mq_get_driver_tag(), all are good to do during getting driver tag. Meantime blk-flush related code is simplified and flush request needn't to update the request table manually any more. Signed-off-by:
-
Ming Lei authored
It is used by blk-mq.c only, so move it to the source file. Suggested-by:
Christoph Hellwig <hch@infradead.org> Signed-off-by:
Hannes Reinecke <hare@suse.de> Cc: Christoph Hellwig <hch@infradead.org> Signed-off-by:
-
Ming Lei authored
blk_mq_get_driver_tag() is only used by blk-mq.c and is supposed to stay in blk-mq.c, so move it and preparing for cleanup code of get/put driver tag. Meantime hctx_may_queue() is moved to header file and it is fine since it is defined as inline always. No functional change. Signed-off-by:
-
Ming Lei authored
More and more drivers want to get batching requests queued from block layer, such as mmc, and tcp based storage drivers. Also current in-tree users have virtio-scsi, virtio-blk and nvme. For none, we already support batching dispatch. But for io scheduler, every time we just take one request from scheduler and pass the single request to blk_mq_dispatch_rq_list(). This way makes batching dispatch not possible when io scheduler is applied. One reason is that we don't want to hurt sequential IO performance, becasue IO merge chance is reduced if more requests are dequeued from scheduler queue. Try to support batching dispatch for io scheduler by starting with the following simple approach: 1) still make sure we can get budget before dequeueing request 2) use hctx->dispatch_busy to evaluate if queue is busy, if it is busy we fackback to non-batching dispatch, otherwise dequeue as many as possible requests from scheduler, and pass them to blk_mq_dispatch_rq_list(). Wrt. 2), we use similar policy for none, and turns out that SCSI SSD performance got improved much. In future, maybe we can develop more intelligent algorithem for batching dispatch. Baolin has tested this patch and found that MMC performance is improved[3]. [1] https://lore.kernel.org/linux-block/20200512075501.GF1531898@T590/#r [2] https://lore.kernel.org/linux-block/fe6bd8b9-6ed9-b225-f80c-314746133722@grimberg.me/ [3] https://lore.kernel.org/linux-block/CADBw62o9eTQDJ9RvNgEqSpXmg6Xcq=2TxH0Hfxhp29uF2W=TXA@mail.gmail.com/Signed-off-by:
Baolin Wang <baolin.wang7@gmail.com> Reviewed-by:
-
