2019-05-01 02:42:43 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2014-05-29 00:15:41 +08:00
|
|
|
/*
|
2016-09-17 22:38:44 +08:00
|
|
|
* Tag allocation using scalable bitmaps. Uses active queue tracking to support
|
|
|
|
* fairer distribution of tags between multiple submitters when a shared tag map
|
|
|
|
* is used.
|
2014-05-29 00:15:41 +08:00
|
|
|
*
|
|
|
|
* Copyright (C) 2013-2014 Jens Axboe
|
|
|
|
*/
|
blk-mq: new multi-queue block IO queueing mechanism
Linux currently has two models for block devices:
- The classic request_fn based approach, where drivers use struct
request units for IO. The block layer provides various helper
functionalities to let drivers share code, things like tag
management, timeout handling, queueing, etc.
- The "stacked" approach, where a driver squeezes in between the
block layer and IO submitter. Since this bypasses the IO stack,
driver generally have to manage everything themselves.
With drivers being written for new high IOPS devices, the classic
request_fn based driver doesn't work well enough. The design dates
back to when both SMP and high IOPS was rare. It has problems with
scaling to bigger machines, and runs into scaling issues even on
smaller machines when you have IOPS in the hundreds of thousands
per device.
The stacked approach is then most often selected as the model
for the driver. But this means that everybody has to re-invent
everything, and along with that we get all the problems again
that the shared approach solved.
This commit introduces blk-mq, block multi queue support. The
design is centered around per-cpu queues for queueing IO, which
then funnel down into x number of hardware submission queues.
We might have a 1:1 mapping between the two, or it might be
an N:M mapping. That all depends on what the hardware supports.
blk-mq provides various helper functions, which include:
- Scalable support for request tagging. Most devices need to
be able to uniquely identify a request both in the driver and
to the hardware. The tagging uses per-cpu caches for freed
tags, to enable cache hot reuse.
- Timeout handling without tracking request on a per-device
basis. Basically the driver should be able to get a notification,
if a request happens to fail.
- Optional support for non 1:1 mappings between issue and
submission queues. blk-mq can redirect IO completions to the
desired location.
- Support for per-request payloads. Drivers almost always need
to associate a request structure with some driver private
command structure. Drivers can tell blk-mq this at init time,
and then any request handed to the driver will have the
required size of memory associated with it.
- Support for merging of IO, and plugging. The stacked model
gets neither of these. Even for high IOPS devices, merging
sequential IO reduces per-command overhead and thus
increases bandwidth.
For now, this is provided as a potential 3rd queueing model, with
the hope being that, as it matures, it can replace both the classic
and stacked model. That would get us back to having just 1 real
model for block devices, leaving the stacked approach to dm/md
devices (as it was originally intended).
Contributions in this patch from the following people:
Shaohua Li <shli@fusionio.com>
Alexander Gordeev <agordeev@redhat.com>
Christoph Hellwig <hch@infradead.org>
Mike Christie <michaelc@cs.wisc.edu>
Matias Bjorling <m@bjorling.me>
Jeff Moyer <jmoyer@redhat.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2013-10-24 16:20:05 +08:00
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/module.h>
|
|
|
|
|
|
|
|
#include <linux/blk-mq.h>
|
2019-07-24 11:48:40 +08:00
|
|
|
#include <linux/delay.h>
|
blk-mq: new multi-queue block IO queueing mechanism
Linux currently has two models for block devices:
- The classic request_fn based approach, where drivers use struct
request units for IO. The block layer provides various helper
functionalities to let drivers share code, things like tag
management, timeout handling, queueing, etc.
- The "stacked" approach, where a driver squeezes in between the
block layer and IO submitter. Since this bypasses the IO stack,
driver generally have to manage everything themselves.
With drivers being written for new high IOPS devices, the classic
request_fn based driver doesn't work well enough. The design dates
back to when both SMP and high IOPS was rare. It has problems with
scaling to bigger machines, and runs into scaling issues even on
smaller machines when you have IOPS in the hundreds of thousands
per device.
The stacked approach is then most often selected as the model
for the driver. But this means that everybody has to re-invent
everything, and along with that we get all the problems again
that the shared approach solved.
This commit introduces blk-mq, block multi queue support. The
design is centered around per-cpu queues for queueing IO, which
then funnel down into x number of hardware submission queues.
We might have a 1:1 mapping between the two, or it might be
an N:M mapping. That all depends on what the hardware supports.
blk-mq provides various helper functions, which include:
- Scalable support for request tagging. Most devices need to
be able to uniquely identify a request both in the driver and
to the hardware. The tagging uses per-cpu caches for freed
tags, to enable cache hot reuse.
- Timeout handling without tracking request on a per-device
basis. Basically the driver should be able to get a notification,
if a request happens to fail.
- Optional support for non 1:1 mappings between issue and
submission queues. blk-mq can redirect IO completions to the
desired location.
- Support for per-request payloads. Drivers almost always need
to associate a request structure with some driver private
command structure. Drivers can tell blk-mq this at init time,
and then any request handed to the driver will have the
required size of memory associated with it.
- Support for merging of IO, and plugging. The stacked model
gets neither of these. Even for high IOPS devices, merging
sequential IO reduces per-command overhead and thus
increases bandwidth.
For now, this is provided as a potential 3rd queueing model, with
the hope being that, as it matures, it can replace both the classic
and stacked model. That would get us back to having just 1 real
model for block devices, leaving the stacked approach to dm/md
devices (as it was originally intended).
Contributions in this patch from the following people:
Shaohua Li <shli@fusionio.com>
Alexander Gordeev <agordeev@redhat.com>
Christoph Hellwig <hch@infradead.org>
Mike Christie <michaelc@cs.wisc.edu>
Matias Bjorling <m@bjorling.me>
Jeff Moyer <jmoyer@redhat.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2013-10-24 16:20:05 +08:00
|
|
|
#include "blk.h"
|
|
|
|
#include "blk-mq.h"
|
|
|
|
#include "blk-mq-tag.h"
|
|
|
|
|
2014-05-14 05:10:52 +08:00
|
|
|
/*
|
|
|
|
* If a previously inactive queue goes active, bump the active user count.
|
2018-08-09 22:34:17 +08:00
|
|
|
* We need to do this before try to allocate driver tag, then even if fail
|
|
|
|
* to get tag when first time, the other shared-tag users could reserve
|
|
|
|
* budget for it.
|
2014-05-14 05:10:52 +08:00
|
|
|
*/
|
|
|
|
bool __blk_mq_tag_busy(struct blk_mq_hw_ctx *hctx)
|
|
|
|
{
|
|
|
|
if (!test_bit(BLK_MQ_S_TAG_ACTIVE, &hctx->state) &&
|
|
|
|
!test_and_set_bit(BLK_MQ_S_TAG_ACTIVE, &hctx->state))
|
|
|
|
atomic_inc(&hctx->tags->active_queues);
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2014-12-23 05:04:42 +08:00
|
|
|
* Wakeup all potentially sleeping on tags
|
2014-05-14 05:10:52 +08:00
|
|
|
*/
|
2014-12-23 05:04:42 +08:00
|
|
|
void blk_mq_tag_wakeup_all(struct blk_mq_tags *tags, bool include_reserve)
|
2014-05-14 05:10:52 +08:00
|
|
|
{
|
2016-09-17 22:38:44 +08:00
|
|
|
sbitmap_queue_wake_all(&tags->bitmap_tags);
|
|
|
|
if (include_reserve)
|
|
|
|
sbitmap_queue_wake_all(&tags->breserved_tags);
|
2014-05-14 05:10:52 +08:00
|
|
|
}
|
|
|
|
|
2014-05-21 01:49:02 +08:00
|
|
|
/*
|
|
|
|
* If a previously busy queue goes inactive, potential waiters could now
|
|
|
|
* be allowed to queue. Wake them up and check.
|
|
|
|
*/
|
|
|
|
void __blk_mq_tag_idle(struct blk_mq_hw_ctx *hctx)
|
|
|
|
{
|
|
|
|
struct blk_mq_tags *tags = hctx->tags;
|
|
|
|
|
|
|
|
if (!test_and_clear_bit(BLK_MQ_S_TAG_ACTIVE, &hctx->state))
|
|
|
|
return;
|
|
|
|
|
|
|
|
atomic_dec(&tags->active_queues);
|
|
|
|
|
2014-12-23 05:04:42 +08:00
|
|
|
blk_mq_tag_wakeup_all(tags, false);
|
2014-05-21 01:49:02 +08:00
|
|
|
}
|
|
|
|
|
2014-05-14 05:10:52 +08:00
|
|
|
/*
|
|
|
|
* For shared tag users, we track the number of currently active users
|
|
|
|
* and attempt to provide a fair share of the tag depth for each of them.
|
|
|
|
*/
|
|
|
|
static inline bool hctx_may_queue(struct blk_mq_hw_ctx *hctx,
|
2016-09-17 22:38:44 +08:00
|
|
|
struct sbitmap_queue *bt)
|
2014-05-14 05:10:52 +08:00
|
|
|
{
|
|
|
|
unsigned int depth, users;
|
|
|
|
|
|
|
|
if (!hctx || !(hctx->flags & BLK_MQ_F_TAG_SHARED))
|
|
|
|
return true;
|
|
|
|
if (!test_bit(BLK_MQ_S_TAG_ACTIVE, &hctx->state))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Don't try dividing an ant
|
|
|
|
*/
|
2016-09-17 22:38:44 +08:00
|
|
|
if (bt->sb.depth == 1)
|
2014-05-14 05:10:52 +08:00
|
|
|
return true;
|
|
|
|
|
|
|
|
users = atomic_read(&hctx->tags->active_queues);
|
|
|
|
if (!users)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Allow at least some tags
|
|
|
|
*/
|
2016-09-17 22:38:44 +08:00
|
|
|
depth = max((bt->sb.depth + users - 1) / users, 4U);
|
2014-05-14 05:10:52 +08:00
|
|
|
return atomic_read(&hctx->nr_active) < depth;
|
|
|
|
}
|
|
|
|
|
2017-01-25 23:11:38 +08:00
|
|
|
static int __blk_mq_get_tag(struct blk_mq_alloc_data *data,
|
|
|
|
struct sbitmap_queue *bt)
|
2014-05-09 23:36:49 +08:00
|
|
|
{
|
2017-01-25 23:11:38 +08:00
|
|
|
if (!(data->flags & BLK_MQ_REQ_INTERNAL) &&
|
|
|
|
!hctx_may_queue(data->hctx, bt))
|
2020-05-29 21:53:12 +08:00
|
|
|
return BLK_MQ_NO_TAG;
|
2017-04-14 15:59:59 +08:00
|
|
|
if (data->shallow_depth)
|
|
|
|
return __sbitmap_queue_get_shallow(bt, data->shallow_depth);
|
|
|
|
else
|
|
|
|
return __sbitmap_queue_get(bt);
|
2014-05-09 23:36:49 +08:00
|
|
|
}
|
|
|
|
|
2017-01-13 23:09:05 +08:00
|
|
|
unsigned int blk_mq_get_tag(struct blk_mq_alloc_data *data)
|
blk-mq: new multi-queue block IO queueing mechanism
Linux currently has two models for block devices:
- The classic request_fn based approach, where drivers use struct
request units for IO. The block layer provides various helper
functionalities to let drivers share code, things like tag
management, timeout handling, queueing, etc.
- The "stacked" approach, where a driver squeezes in between the
block layer and IO submitter. Since this bypasses the IO stack,
driver generally have to manage everything themselves.
With drivers being written for new high IOPS devices, the classic
request_fn based driver doesn't work well enough. The design dates
back to when both SMP and high IOPS was rare. It has problems with
scaling to bigger machines, and runs into scaling issues even on
smaller machines when you have IOPS in the hundreds of thousands
per device.
The stacked approach is then most often selected as the model
for the driver. But this means that everybody has to re-invent
everything, and along with that we get all the problems again
that the shared approach solved.
This commit introduces blk-mq, block multi queue support. The
design is centered around per-cpu queues for queueing IO, which
then funnel down into x number of hardware submission queues.
We might have a 1:1 mapping between the two, or it might be
an N:M mapping. That all depends on what the hardware supports.
blk-mq provides various helper functions, which include:
- Scalable support for request tagging. Most devices need to
be able to uniquely identify a request both in the driver and
to the hardware. The tagging uses per-cpu caches for freed
tags, to enable cache hot reuse.
- Timeout handling without tracking request on a per-device
basis. Basically the driver should be able to get a notification,
if a request happens to fail.
- Optional support for non 1:1 mappings between issue and
submission queues. blk-mq can redirect IO completions to the
desired location.
- Support for per-request payloads. Drivers almost always need
to associate a request structure with some driver private
command structure. Drivers can tell blk-mq this at init time,
and then any request handed to the driver will have the
required size of memory associated with it.
- Support for merging of IO, and plugging. The stacked model
gets neither of these. Even for high IOPS devices, merging
sequential IO reduces per-command overhead and thus
increases bandwidth.
For now, this is provided as a potential 3rd queueing model, with
the hope being that, as it matures, it can replace both the classic
and stacked model. That would get us back to having just 1 real
model for block devices, leaving the stacked approach to dm/md
devices (as it was originally intended).
Contributions in this patch from the following people:
Shaohua Li <shli@fusionio.com>
Alexander Gordeev <agordeev@redhat.com>
Christoph Hellwig <hch@infradead.org>
Mike Christie <michaelc@cs.wisc.edu>
Matias Bjorling <m@bjorling.me>
Jeff Moyer <jmoyer@redhat.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2013-10-24 16:20:05 +08:00
|
|
|
{
|
2017-01-13 23:09:05 +08:00
|
|
|
struct blk_mq_tags *tags = blk_mq_tags_from_data(data);
|
|
|
|
struct sbitmap_queue *bt;
|
2016-09-17 22:38:44 +08:00
|
|
|
struct sbq_wait_state *ws;
|
2018-11-30 08:36:41 +08:00
|
|
|
DEFINE_SBQ_WAIT(wait);
|
2017-01-13 23:09:05 +08:00
|
|
|
unsigned int tag_offset;
|
blk-mq: new multi-queue block IO queueing mechanism
Linux currently has two models for block devices:
- The classic request_fn based approach, where drivers use struct
request units for IO. The block layer provides various helper
functionalities to let drivers share code, things like tag
management, timeout handling, queueing, etc.
- The "stacked" approach, where a driver squeezes in between the
block layer and IO submitter. Since this bypasses the IO stack,
driver generally have to manage everything themselves.
With drivers being written for new high IOPS devices, the classic
request_fn based driver doesn't work well enough. The design dates
back to when both SMP and high IOPS was rare. It has problems with
scaling to bigger machines, and runs into scaling issues even on
smaller machines when you have IOPS in the hundreds of thousands
per device.
The stacked approach is then most often selected as the model
for the driver. But this means that everybody has to re-invent
everything, and along with that we get all the problems again
that the shared approach solved.
This commit introduces blk-mq, block multi queue support. The
design is centered around per-cpu queues for queueing IO, which
then funnel down into x number of hardware submission queues.
We might have a 1:1 mapping between the two, or it might be
an N:M mapping. That all depends on what the hardware supports.
blk-mq provides various helper functions, which include:
- Scalable support for request tagging. Most devices need to
be able to uniquely identify a request both in the driver and
to the hardware. The tagging uses per-cpu caches for freed
tags, to enable cache hot reuse.
- Timeout handling without tracking request on a per-device
basis. Basically the driver should be able to get a notification,
if a request happens to fail.
- Optional support for non 1:1 mappings between issue and
submission queues. blk-mq can redirect IO completions to the
desired location.
- Support for per-request payloads. Drivers almost always need
to associate a request structure with some driver private
command structure. Drivers can tell blk-mq this at init time,
and then any request handed to the driver will have the
required size of memory associated with it.
- Support for merging of IO, and plugging. The stacked model
gets neither of these. Even for high IOPS devices, merging
sequential IO reduces per-command overhead and thus
increases bandwidth.
For now, this is provided as a potential 3rd queueing model, with
the hope being that, as it matures, it can replace both the classic
and stacked model. That would get us back to having just 1 real
model for block devices, leaving the stacked approach to dm/md
devices (as it was originally intended).
Contributions in this patch from the following people:
Shaohua Li <shli@fusionio.com>
Alexander Gordeev <agordeev@redhat.com>
Christoph Hellwig <hch@infradead.org>
Mike Christie <michaelc@cs.wisc.edu>
Matias Bjorling <m@bjorling.me>
Jeff Moyer <jmoyer@redhat.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2013-10-24 16:20:05 +08:00
|
|
|
int tag;
|
|
|
|
|
2017-01-13 23:09:05 +08:00
|
|
|
if (data->flags & BLK_MQ_REQ_RESERVED) {
|
|
|
|
if (unlikely(!tags->nr_reserved_tags)) {
|
|
|
|
WARN_ON_ONCE(1);
|
2020-05-29 21:53:11 +08:00
|
|
|
return BLK_MQ_NO_TAG;
|
2017-01-13 23:09:05 +08:00
|
|
|
}
|
|
|
|
bt = &tags->breserved_tags;
|
|
|
|
tag_offset = 0;
|
|
|
|
} else {
|
|
|
|
bt = &tags->bitmap_tags;
|
|
|
|
tag_offset = tags->nr_reserved_tags;
|
|
|
|
}
|
|
|
|
|
2017-01-25 23:11:38 +08:00
|
|
|
tag = __blk_mq_get_tag(data, bt);
|
2020-05-29 21:53:12 +08:00
|
|
|
if (tag != BLK_MQ_NO_TAG)
|
2017-01-13 23:09:05 +08:00
|
|
|
goto found_tag;
|
2014-05-09 23:36:49 +08:00
|
|
|
|
2015-11-26 16:13:05 +08:00
|
|
|
if (data->flags & BLK_MQ_REQ_NOWAIT)
|
2020-05-29 21:53:11 +08:00
|
|
|
return BLK_MQ_NO_TAG;
|
2014-05-09 23:36:49 +08:00
|
|
|
|
2017-01-13 23:09:05 +08:00
|
|
|
ws = bt_wait_ptr(bt, data->hctx);
|
2014-05-09 23:36:49 +08:00
|
|
|
do {
|
2018-05-25 01:00:39 +08:00
|
|
|
struct sbitmap_queue *bt_prev;
|
|
|
|
|
2014-12-08 23:46:34 +08:00
|
|
|
/*
|
|
|
|
* We're out of tags on this hardware queue, kick any
|
|
|
|
* pending IO submits before going to sleep waiting for
|
2017-01-19 22:39:17 +08:00
|
|
|
* some to complete.
|
2014-12-08 23:46:34 +08:00
|
|
|
*/
|
2017-01-19 22:39:17 +08:00
|
|
|
blk_mq_run_hw_queue(data->hctx, false);
|
2014-12-08 23:46:34 +08:00
|
|
|
|
2014-12-08 23:49:06 +08:00
|
|
|
/*
|
|
|
|
* Retry tag allocation after running the hardware queue,
|
|
|
|
* as running the queue may also have found completions.
|
|
|
|
*/
|
2017-01-25 23:11:38 +08:00
|
|
|
tag = __blk_mq_get_tag(data, bt);
|
2020-05-29 21:53:12 +08:00
|
|
|
if (tag != BLK_MQ_NO_TAG)
|
2014-12-08 23:49:06 +08:00
|
|
|
break;
|
|
|
|
|
2018-11-30 08:36:41 +08:00
|
|
|
sbitmap_prepare_to_wait(bt, ws, &wait, TASK_UNINTERRUPTIBLE);
|
2017-11-15 01:24:58 +08:00
|
|
|
|
|
|
|
tag = __blk_mq_get_tag(data, bt);
|
2020-05-29 21:53:12 +08:00
|
|
|
if (tag != BLK_MQ_NO_TAG)
|
2017-11-15 01:24:58 +08:00
|
|
|
break;
|
|
|
|
|
2018-05-25 01:00:39 +08:00
|
|
|
bt_prev = bt;
|
2014-05-09 23:36:49 +08:00
|
|
|
io_schedule();
|
2014-06-01 00:43:37 +08:00
|
|
|
|
2018-11-30 08:36:41 +08:00
|
|
|
sbitmap_finish_wait(bt, ws, &wait);
|
|
|
|
|
2014-06-01 00:43:37 +08:00
|
|
|
data->ctx = blk_mq_get_ctx(data->q);
|
2018-10-30 03:11:38 +08:00
|
|
|
data->hctx = blk_mq_map_queue(data->q, data->cmd_flags,
|
2019-01-24 18:25:32 +08:00
|
|
|
data->ctx);
|
2017-01-13 23:09:05 +08:00
|
|
|
tags = blk_mq_tags_from_data(data);
|
|
|
|
if (data->flags & BLK_MQ_REQ_RESERVED)
|
|
|
|
bt = &tags->breserved_tags;
|
|
|
|
else
|
|
|
|
bt = &tags->bitmap_tags;
|
|
|
|
|
2018-05-25 01:00:39 +08:00
|
|
|
/*
|
|
|
|
* If destination hw queue is changed, fake wake up on
|
|
|
|
* previous queue for compensating the wake up miss, so
|
|
|
|
* other allocations on previous queue won't be starved.
|
|
|
|
*/
|
|
|
|
if (bt != bt_prev)
|
|
|
|
sbitmap_queue_wake_up(bt_prev);
|
|
|
|
|
2017-01-13 23:09:05 +08:00
|
|
|
ws = bt_wait_ptr(bt, data->hctx);
|
2014-05-09 23:36:49 +08:00
|
|
|
} while (1);
|
|
|
|
|
2018-11-30 08:36:41 +08:00
|
|
|
sbitmap_finish_wait(bt, ws, &wait);
|
blk-mq: new multi-queue block IO queueing mechanism
Linux currently has two models for block devices:
- The classic request_fn based approach, where drivers use struct
request units for IO. The block layer provides various helper
functionalities to let drivers share code, things like tag
management, timeout handling, queueing, etc.
- The "stacked" approach, where a driver squeezes in between the
block layer and IO submitter. Since this bypasses the IO stack,
driver generally have to manage everything themselves.
With drivers being written for new high IOPS devices, the classic
request_fn based driver doesn't work well enough. The design dates
back to when both SMP and high IOPS was rare. It has problems with
scaling to bigger machines, and runs into scaling issues even on
smaller machines when you have IOPS in the hundreds of thousands
per device.
The stacked approach is then most often selected as the model
for the driver. But this means that everybody has to re-invent
everything, and along with that we get all the problems again
that the shared approach solved.
This commit introduces blk-mq, block multi queue support. The
design is centered around per-cpu queues for queueing IO, which
then funnel down into x number of hardware submission queues.
We might have a 1:1 mapping between the two, or it might be
an N:M mapping. That all depends on what the hardware supports.
blk-mq provides various helper functions, which include:
- Scalable support for request tagging. Most devices need to
be able to uniquely identify a request both in the driver and
to the hardware. The tagging uses per-cpu caches for freed
tags, to enable cache hot reuse.
- Timeout handling without tracking request on a per-device
basis. Basically the driver should be able to get a notification,
if a request happens to fail.
- Optional support for non 1:1 mappings between issue and
submission queues. blk-mq can redirect IO completions to the
desired location.
- Support for per-request payloads. Drivers almost always need
to associate a request structure with some driver private
command structure. Drivers can tell blk-mq this at init time,
and then any request handed to the driver will have the
required size of memory associated with it.
- Support for merging of IO, and plugging. The stacked model
gets neither of these. Even for high IOPS devices, merging
sequential IO reduces per-command overhead and thus
increases bandwidth.
For now, this is provided as a potential 3rd queueing model, with
the hope being that, as it matures, it can replace both the classic
and stacked model. That would get us back to having just 1 real
model for block devices, leaving the stacked approach to dm/md
devices (as it was originally intended).
Contributions in this patch from the following people:
Shaohua Li <shli@fusionio.com>
Alexander Gordeev <agordeev@redhat.com>
Christoph Hellwig <hch@infradead.org>
Mike Christie <michaelc@cs.wisc.edu>
Matias Bjorling <m@bjorling.me>
Jeff Moyer <jmoyer@redhat.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2013-10-24 16:20:05 +08:00
|
|
|
|
2017-01-13 23:09:05 +08:00
|
|
|
found_tag:
|
|
|
|
return tag + tag_offset;
|
blk-mq: new multi-queue block IO queueing mechanism
Linux currently has two models for block devices:
- The classic request_fn based approach, where drivers use struct
request units for IO. The block layer provides various helper
functionalities to let drivers share code, things like tag
management, timeout handling, queueing, etc.
- The "stacked" approach, where a driver squeezes in between the
block layer and IO submitter. Since this bypasses the IO stack,
driver generally have to manage everything themselves.
With drivers being written for new high IOPS devices, the classic
request_fn based driver doesn't work well enough. The design dates
back to when both SMP and high IOPS was rare. It has problems with
scaling to bigger machines, and runs into scaling issues even on
smaller machines when you have IOPS in the hundreds of thousands
per device.
The stacked approach is then most often selected as the model
for the driver. But this means that everybody has to re-invent
everything, and along with that we get all the problems again
that the shared approach solved.
This commit introduces blk-mq, block multi queue support. The
design is centered around per-cpu queues for queueing IO, which
then funnel down into x number of hardware submission queues.
We might have a 1:1 mapping between the two, or it might be
an N:M mapping. That all depends on what the hardware supports.
blk-mq provides various helper functions, which include:
- Scalable support for request tagging. Most devices need to
be able to uniquely identify a request both in the driver and
to the hardware. The tagging uses per-cpu caches for freed
tags, to enable cache hot reuse.
- Timeout handling without tracking request on a per-device
basis. Basically the driver should be able to get a notification,
if a request happens to fail.
- Optional support for non 1:1 mappings between issue and
submission queues. blk-mq can redirect IO completions to the
desired location.
- Support for per-request payloads. Drivers almost always need
to associate a request structure with some driver private
command structure. Drivers can tell blk-mq this at init time,
and then any request handed to the driver will have the
required size of memory associated with it.
- Support for merging of IO, and plugging. The stacked model
gets neither of these. Even for high IOPS devices, merging
sequential IO reduces per-command overhead and thus
increases bandwidth.
For now, this is provided as a potential 3rd queueing model, with
the hope being that, as it matures, it can replace both the classic
and stacked model. That would get us back to having just 1 real
model for block devices, leaving the stacked approach to dm/md
devices (as it was originally intended).
Contributions in this patch from the following people:
Shaohua Li <shli@fusionio.com>
Alexander Gordeev <agordeev@redhat.com>
Christoph Hellwig <hch@infradead.org>
Mike Christie <michaelc@cs.wisc.edu>
Matias Bjorling <m@bjorling.me>
Jeff Moyer <jmoyer@redhat.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2013-10-24 16:20:05 +08:00
|
|
|
}
|
|
|
|
|
2020-02-26 20:10:15 +08:00
|
|
|
void blk_mq_put_tag(struct blk_mq_tags *tags, struct blk_mq_ctx *ctx,
|
|
|
|
unsigned int tag)
|
blk-mq: new multi-queue block IO queueing mechanism
Linux currently has two models for block devices:
- The classic request_fn based approach, where drivers use struct
request units for IO. The block layer provides various helper
functionalities to let drivers share code, things like tag
management, timeout handling, queueing, etc.
- The "stacked" approach, where a driver squeezes in between the
block layer and IO submitter. Since this bypasses the IO stack,
driver generally have to manage everything themselves.
With drivers being written for new high IOPS devices, the classic
request_fn based driver doesn't work well enough. The design dates
back to when both SMP and high IOPS was rare. It has problems with
scaling to bigger machines, and runs into scaling issues even on
smaller machines when you have IOPS in the hundreds of thousands
per device.
The stacked approach is then most often selected as the model
for the driver. But this means that everybody has to re-invent
everything, and along with that we get all the problems again
that the shared approach solved.
This commit introduces blk-mq, block multi queue support. The
design is centered around per-cpu queues for queueing IO, which
then funnel down into x number of hardware submission queues.
We might have a 1:1 mapping between the two, or it might be
an N:M mapping. That all depends on what the hardware supports.
blk-mq provides various helper functions, which include:
- Scalable support for request tagging. Most devices need to
be able to uniquely identify a request both in the driver and
to the hardware. The tagging uses per-cpu caches for freed
tags, to enable cache hot reuse.
- Timeout handling without tracking request on a per-device
basis. Basically the driver should be able to get a notification,
if a request happens to fail.
- Optional support for non 1:1 mappings between issue and
submission queues. blk-mq can redirect IO completions to the
desired location.
- Support for per-request payloads. Drivers almost always need
to associate a request structure with some driver private
command structure. Drivers can tell blk-mq this at init time,
and then any request handed to the driver will have the
required size of memory associated with it.
- Support for merging of IO, and plugging. The stacked model
gets neither of these. Even for high IOPS devices, merging
sequential IO reduces per-command overhead and thus
increases bandwidth.
For now, this is provided as a potential 3rd queueing model, with
the hope being that, as it matures, it can replace both the classic
and stacked model. That would get us back to having just 1 real
model for block devices, leaving the stacked approach to dm/md
devices (as it was originally intended).
Contributions in this patch from the following people:
Shaohua Li <shli@fusionio.com>
Alexander Gordeev <agordeev@redhat.com>
Christoph Hellwig <hch@infradead.org>
Mike Christie <michaelc@cs.wisc.edu>
Matias Bjorling <m@bjorling.me>
Jeff Moyer <jmoyer@redhat.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2013-10-24 16:20:05 +08:00
|
|
|
{
|
2017-02-28 01:04:39 +08:00
|
|
|
if (!blk_mq_tag_is_reserved(tags, tag)) {
|
2014-05-09 23:36:49 +08:00
|
|
|
const int real_tag = tag - tags->nr_reserved_tags;
|
|
|
|
|
2014-11-25 06:52:30 +08:00
|
|
|
BUG_ON(real_tag >= tags->nr_tags);
|
2016-09-17 16:28:24 +08:00
|
|
|
sbitmap_queue_clear(&tags->bitmap_tags, real_tag, ctx->cpu);
|
2014-11-25 06:52:30 +08:00
|
|
|
} else {
|
|
|
|
BUG_ON(tag >= tags->nr_reserved_tags);
|
2016-09-17 16:28:24 +08:00
|
|
|
sbitmap_queue_clear(&tags->breserved_tags, tag, ctx->cpu);
|
2014-11-25 06:52:30 +08:00
|
|
|
}
|
blk-mq: new multi-queue block IO queueing mechanism
Linux currently has two models for block devices:
- The classic request_fn based approach, where drivers use struct
request units for IO. The block layer provides various helper
functionalities to let drivers share code, things like tag
management, timeout handling, queueing, etc.
- The "stacked" approach, where a driver squeezes in between the
block layer and IO submitter. Since this bypasses the IO stack,
driver generally have to manage everything themselves.
With drivers being written for new high IOPS devices, the classic
request_fn based driver doesn't work well enough. The design dates
back to when both SMP and high IOPS was rare. It has problems with
scaling to bigger machines, and runs into scaling issues even on
smaller machines when you have IOPS in the hundreds of thousands
per device.
The stacked approach is then most often selected as the model
for the driver. But this means that everybody has to re-invent
everything, and along with that we get all the problems again
that the shared approach solved.
This commit introduces blk-mq, block multi queue support. The
design is centered around per-cpu queues for queueing IO, which
then funnel down into x number of hardware submission queues.
We might have a 1:1 mapping between the two, or it might be
an N:M mapping. That all depends on what the hardware supports.
blk-mq provides various helper functions, which include:
- Scalable support for request tagging. Most devices need to
be able to uniquely identify a request both in the driver and
to the hardware. The tagging uses per-cpu caches for freed
tags, to enable cache hot reuse.
- Timeout handling without tracking request on a per-device
basis. Basically the driver should be able to get a notification,
if a request happens to fail.
- Optional support for non 1:1 mappings between issue and
submission queues. blk-mq can redirect IO completions to the
desired location.
- Support for per-request payloads. Drivers almost always need
to associate a request structure with some driver private
command structure. Drivers can tell blk-mq this at init time,
and then any request handed to the driver will have the
required size of memory associated with it.
- Support for merging of IO, and plugging. The stacked model
gets neither of these. Even for high IOPS devices, merging
sequential IO reduces per-command overhead and thus
increases bandwidth.
For now, this is provided as a potential 3rd queueing model, with
the hope being that, as it matures, it can replace both the classic
and stacked model. That would get us back to having just 1 real
model for block devices, leaving the stacked approach to dm/md
devices (as it was originally intended).
Contributions in this patch from the following people:
Shaohua Li <shli@fusionio.com>
Alexander Gordeev <agordeev@redhat.com>
Christoph Hellwig <hch@infradead.org>
Mike Christie <michaelc@cs.wisc.edu>
Matias Bjorling <m@bjorling.me>
Jeff Moyer <jmoyer@redhat.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2013-10-24 16:20:05 +08:00
|
|
|
}
|
|
|
|
|
2016-09-17 22:38:44 +08:00
|
|
|
struct bt_iter_data {
|
|
|
|
struct blk_mq_hw_ctx *hctx;
|
|
|
|
busy_iter_fn *fn;
|
|
|
|
void *data;
|
|
|
|
bool reserved;
|
|
|
|
};
|
|
|
|
|
|
|
|
static bool bt_iter(struct sbitmap *bitmap, unsigned int bitnr, void *data)
|
blk-mq: new multi-queue block IO queueing mechanism
Linux currently has two models for block devices:
- The classic request_fn based approach, where drivers use struct
request units for IO. The block layer provides various helper
functionalities to let drivers share code, things like tag
management, timeout handling, queueing, etc.
- The "stacked" approach, where a driver squeezes in between the
block layer and IO submitter. Since this bypasses the IO stack,
driver generally have to manage everything themselves.
With drivers being written for new high IOPS devices, the classic
request_fn based driver doesn't work well enough. The design dates
back to when both SMP and high IOPS was rare. It has problems with
scaling to bigger machines, and runs into scaling issues even on
smaller machines when you have IOPS in the hundreds of thousands
per device.
The stacked approach is then most often selected as the model
for the driver. But this means that everybody has to re-invent
everything, and along with that we get all the problems again
that the shared approach solved.
This commit introduces blk-mq, block multi queue support. The
design is centered around per-cpu queues for queueing IO, which
then funnel down into x number of hardware submission queues.
We might have a 1:1 mapping between the two, or it might be
an N:M mapping. That all depends on what the hardware supports.
blk-mq provides various helper functions, which include:
- Scalable support for request tagging. Most devices need to
be able to uniquely identify a request both in the driver and
to the hardware. The tagging uses per-cpu caches for freed
tags, to enable cache hot reuse.
- Timeout handling without tracking request on a per-device
basis. Basically the driver should be able to get a notification,
if a request happens to fail.
- Optional support for non 1:1 mappings between issue and
submission queues. blk-mq can redirect IO completions to the
desired location.
- Support for per-request payloads. Drivers almost always need
to associate a request structure with some driver private
command structure. Drivers can tell blk-mq this at init time,
and then any request handed to the driver will have the
required size of memory associated with it.
- Support for merging of IO, and plugging. The stacked model
gets neither of these. Even for high IOPS devices, merging
sequential IO reduces per-command overhead and thus
increases bandwidth.
For now, this is provided as a potential 3rd queueing model, with
the hope being that, as it matures, it can replace both the classic
and stacked model. That would get us back to having just 1 real
model for block devices, leaving the stacked approach to dm/md
devices (as it was originally intended).
Contributions in this patch from the following people:
Shaohua Li <shli@fusionio.com>
Alexander Gordeev <agordeev@redhat.com>
Christoph Hellwig <hch@infradead.org>
Mike Christie <michaelc@cs.wisc.edu>
Matias Bjorling <m@bjorling.me>
Jeff Moyer <jmoyer@redhat.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2013-10-24 16:20:05 +08:00
|
|
|
{
|
2016-09-17 22:38:44 +08:00
|
|
|
struct bt_iter_data *iter_data = data;
|
|
|
|
struct blk_mq_hw_ctx *hctx = iter_data->hctx;
|
|
|
|
struct blk_mq_tags *tags = hctx->tags;
|
|
|
|
bool reserved = iter_data->reserved;
|
2014-09-14 07:40:11 +08:00
|
|
|
struct request *rq;
|
2014-05-09 23:36:49 +08:00
|
|
|
|
2016-09-17 22:38:44 +08:00
|
|
|
if (!reserved)
|
|
|
|
bitnr += tags->nr_reserved_tags;
|
|
|
|
rq = tags->rqs[bitnr];
|
2014-05-09 23:36:49 +08:00
|
|
|
|
2017-08-05 03:37:03 +08:00
|
|
|
/*
|
|
|
|
* We can hit rq == NULL here, because the tagging functions
|
2018-09-22 04:34:46 +08:00
|
|
|
* test and set the bit before assigning ->rqs[].
|
2017-08-05 03:37:03 +08:00
|
|
|
*/
|
|
|
|
if (rq && rq->q == hctx->queue)
|
2018-11-09 01:24:07 +08:00
|
|
|
return iter_data->fn(hctx, rq, iter_data->data, reserved);
|
2016-09-17 22:38:44 +08:00
|
|
|
return true;
|
|
|
|
}
|
2014-05-09 23:36:49 +08:00
|
|
|
|
2018-09-22 04:34:46 +08:00
|
|
|
/**
|
|
|
|
* bt_for_each - iterate over the requests associated with a hardware queue
|
|
|
|
* @hctx: Hardware queue to examine.
|
|
|
|
* @bt: sbitmap to examine. This is either the breserved_tags member
|
|
|
|
* or the bitmap_tags member of struct blk_mq_tags.
|
|
|
|
* @fn: Pointer to the function that will be called for each request
|
|
|
|
* associated with @hctx that has been assigned a driver tag.
|
|
|
|
* @fn will be called as follows: @fn(@hctx, rq, @data, @reserved)
|
2018-11-09 02:09:50 +08:00
|
|
|
* where rq is a pointer to a request. Return true to continue
|
|
|
|
* iterating tags, false to stop.
|
2018-09-22 04:34:46 +08:00
|
|
|
* @data: Will be passed as third argument to @fn.
|
|
|
|
* @reserved: Indicates whether @bt is the breserved_tags member or the
|
|
|
|
* bitmap_tags member of struct blk_mq_tags.
|
|
|
|
*/
|
2016-09-17 22:38:44 +08:00
|
|
|
static void bt_for_each(struct blk_mq_hw_ctx *hctx, struct sbitmap_queue *bt,
|
|
|
|
busy_iter_fn *fn, void *data, bool reserved)
|
|
|
|
{
|
|
|
|
struct bt_iter_data iter_data = {
|
|
|
|
.hctx = hctx,
|
|
|
|
.fn = fn,
|
|
|
|
.data = data,
|
|
|
|
.reserved = reserved,
|
|
|
|
};
|
|
|
|
|
|
|
|
sbitmap_for_each_set(&bt->sb, bt_iter, &iter_data);
|
blk-mq: new multi-queue block IO queueing mechanism
Linux currently has two models for block devices:
- The classic request_fn based approach, where drivers use struct
request units for IO. The block layer provides various helper
functionalities to let drivers share code, things like tag
management, timeout handling, queueing, etc.
- The "stacked" approach, where a driver squeezes in between the
block layer and IO submitter. Since this bypasses the IO stack,
driver generally have to manage everything themselves.
With drivers being written for new high IOPS devices, the classic
request_fn based driver doesn't work well enough. The design dates
back to when both SMP and high IOPS was rare. It has problems with
scaling to bigger machines, and runs into scaling issues even on
smaller machines when you have IOPS in the hundreds of thousands
per device.
The stacked approach is then most often selected as the model
for the driver. But this means that everybody has to re-invent
everything, and along with that we get all the problems again
that the shared approach solved.
This commit introduces blk-mq, block multi queue support. The
design is centered around per-cpu queues for queueing IO, which
then funnel down into x number of hardware submission queues.
We might have a 1:1 mapping between the two, or it might be
an N:M mapping. That all depends on what the hardware supports.
blk-mq provides various helper functions, which include:
- Scalable support for request tagging. Most devices need to
be able to uniquely identify a request both in the driver and
to the hardware. The tagging uses per-cpu caches for freed
tags, to enable cache hot reuse.
- Timeout handling without tracking request on a per-device
basis. Basically the driver should be able to get a notification,
if a request happens to fail.
- Optional support for non 1:1 mappings between issue and
submission queues. blk-mq can redirect IO completions to the
desired location.
- Support for per-request payloads. Drivers almost always need
to associate a request structure with some driver private
command structure. Drivers can tell blk-mq this at init time,
and then any request handed to the driver will have the
required size of memory associated with it.
- Support for merging of IO, and plugging. The stacked model
gets neither of these. Even for high IOPS devices, merging
sequential IO reduces per-command overhead and thus
increases bandwidth.
For now, this is provided as a potential 3rd queueing model, with
the hope being that, as it matures, it can replace both the classic
and stacked model. That would get us back to having just 1 real
model for block devices, leaving the stacked approach to dm/md
devices (as it was originally intended).
Contributions in this patch from the following people:
Shaohua Li <shli@fusionio.com>
Alexander Gordeev <agordeev@redhat.com>
Christoph Hellwig <hch@infradead.org>
Mike Christie <michaelc@cs.wisc.edu>
Matias Bjorling <m@bjorling.me>
Jeff Moyer <jmoyer@redhat.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2013-10-24 16:20:05 +08:00
|
|
|
}
|
|
|
|
|
2016-09-17 22:38:44 +08:00
|
|
|
struct bt_tags_iter_data {
|
|
|
|
struct blk_mq_tags *tags;
|
|
|
|
busy_tag_iter_fn *fn;
|
|
|
|
void *data;
|
2020-05-29 21:53:14 +08:00
|
|
|
unsigned int flags;
|
2016-09-17 22:38:44 +08:00
|
|
|
};
|
|
|
|
|
2020-05-29 21:53:14 +08:00
|
|
|
#define BT_TAG_ITER_RESERVED (1 << 0)
|
|
|
|
#define BT_TAG_ITER_STARTED (1 << 1)
|
|
|
|
|
2016-09-17 22:38:44 +08:00
|
|
|
static bool bt_tags_iter(struct sbitmap *bitmap, unsigned int bitnr, void *data)
|
2015-06-01 23:29:53 +08:00
|
|
|
{
|
2016-09-17 22:38:44 +08:00
|
|
|
struct bt_tags_iter_data *iter_data = data;
|
|
|
|
struct blk_mq_tags *tags = iter_data->tags;
|
2020-05-29 21:53:14 +08:00
|
|
|
bool reserved = iter_data->flags & BT_TAG_ITER_RESERVED;
|
2015-06-01 23:29:53 +08:00
|
|
|
struct request *rq;
|
|
|
|
|
2016-09-17 22:38:44 +08:00
|
|
|
if (!reserved)
|
|
|
|
bitnr += tags->nr_reserved_tags;
|
2017-08-05 03:37:03 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We can hit rq == NULL here, because the tagging functions
|
|
|
|
* test and set the bit before assining ->rqs[].
|
|
|
|
*/
|
2016-09-17 22:38:44 +08:00
|
|
|
rq = tags->rqs[bitnr];
|
2020-05-29 21:53:14 +08:00
|
|
|
if (!rq)
|
|
|
|
return true;
|
|
|
|
if ((iter_data->flags & BT_TAG_ITER_STARTED) &&
|
|
|
|
!blk_mq_request_started(rq))
|
|
|
|
return true;
|
|
|
|
return iter_data->fn(rq, iter_data->data, reserved);
|
2016-09-17 22:38:44 +08:00
|
|
|
}
|
|
|
|
|
2018-09-22 04:34:46 +08:00
|
|
|
/**
|
|
|
|
* bt_tags_for_each - iterate over the requests in a tag map
|
|
|
|
* @tags: Tag map to iterate over.
|
|
|
|
* @bt: sbitmap to examine. This is either the breserved_tags member
|
|
|
|
* or the bitmap_tags member of struct blk_mq_tags.
|
|
|
|
* @fn: Pointer to the function that will be called for each started
|
|
|
|
* request. @fn will be called as follows: @fn(rq, @data,
|
2018-11-09 02:09:50 +08:00
|
|
|
* @reserved) where rq is a pointer to a request. Return true
|
|
|
|
* to continue iterating tags, false to stop.
|
2018-09-22 04:34:46 +08:00
|
|
|
* @data: Will be passed as second argument to @fn.
|
2020-05-29 21:53:14 +08:00
|
|
|
* @flags: BT_TAG_ITER_*
|
2018-09-22 04:34:46 +08:00
|
|
|
*/
|
2016-09-17 22:38:44 +08:00
|
|
|
static void bt_tags_for_each(struct blk_mq_tags *tags, struct sbitmap_queue *bt,
|
2020-05-29 21:53:14 +08:00
|
|
|
busy_tag_iter_fn *fn, void *data, unsigned int flags)
|
2016-09-17 22:38:44 +08:00
|
|
|
{
|
|
|
|
struct bt_tags_iter_data iter_data = {
|
|
|
|
.tags = tags,
|
|
|
|
.fn = fn,
|
|
|
|
.data = data,
|
2020-05-29 21:53:14 +08:00
|
|
|
.flags = flags,
|
2016-09-17 22:38:44 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
if (tags->rqs)
|
|
|
|
sbitmap_for_each_set(&bt->sb, bt_tags_iter, &iter_data);
|
2015-06-01 23:29:53 +08:00
|
|
|
}
|
|
|
|
|
2020-05-29 21:53:14 +08:00
|
|
|
static void __blk_mq_all_tag_iter(struct blk_mq_tags *tags,
|
|
|
|
busy_tag_iter_fn *fn, void *priv, unsigned int flags)
|
|
|
|
{
|
|
|
|
WARN_ON_ONCE(flags & BT_TAG_ITER_RESERVED);
|
|
|
|
|
|
|
|
if (tags->nr_reserved_tags)
|
|
|
|
bt_tags_for_each(tags, &tags->breserved_tags, fn, priv,
|
|
|
|
flags | BT_TAG_ITER_RESERVED);
|
|
|
|
bt_tags_for_each(tags, &tags->bitmap_tags, fn, priv, flags);
|
|
|
|
}
|
|
|
|
|
2018-09-22 04:34:46 +08:00
|
|
|
/**
|
2020-05-29 21:53:14 +08:00
|
|
|
* blk_mq_all_tag_iter - iterate over all requests in a tag map
|
2018-09-22 04:34:46 +08:00
|
|
|
* @tags: Tag map to iterate over.
|
2020-05-29 21:53:14 +08:00
|
|
|
* @fn: Pointer to the function that will be called for each
|
2018-09-22 04:34:46 +08:00
|
|
|
* request. @fn will be called as follows: @fn(rq, @priv,
|
|
|
|
* reserved) where rq is a pointer to a request. 'reserved'
|
2018-11-09 02:09:50 +08:00
|
|
|
* indicates whether or not @rq is a reserved request. Return
|
|
|
|
* true to continue iterating tags, false to stop.
|
2018-09-22 04:34:46 +08:00
|
|
|
* @priv: Will be passed as second argument to @fn.
|
|
|
|
*/
|
2020-05-29 21:53:14 +08:00
|
|
|
void blk_mq_all_tag_iter(struct blk_mq_tags *tags, busy_tag_iter_fn *fn,
|
|
|
|
void *priv)
|
2015-06-01 23:29:53 +08:00
|
|
|
{
|
2020-05-29 21:53:14 +08:00
|
|
|
return __blk_mq_all_tag_iter(tags, fn, priv, 0);
|
2015-06-01 23:29:53 +08:00
|
|
|
}
|
|
|
|
|
2018-09-22 04:34:46 +08:00
|
|
|
/**
|
|
|
|
* blk_mq_tagset_busy_iter - iterate over all started requests in a tag set
|
|
|
|
* @tagset: Tag set to iterate over.
|
|
|
|
* @fn: Pointer to the function that will be called for each started
|
|
|
|
* request. @fn will be called as follows: @fn(rq, @priv,
|
|
|
|
* reserved) where rq is a pointer to a request. 'reserved'
|
2018-11-09 02:09:50 +08:00
|
|
|
* indicates whether or not @rq is a reserved request. Return
|
|
|
|
* true to continue iterating tags, false to stop.
|
2018-09-22 04:34:46 +08:00
|
|
|
* @priv: Will be passed as second argument to @fn.
|
|
|
|
*/
|
2016-03-10 19:58:46 +08:00
|
|
|
void blk_mq_tagset_busy_iter(struct blk_mq_tag_set *tagset,
|
|
|
|
busy_tag_iter_fn *fn, void *priv)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < tagset->nr_hw_queues; i++) {
|
|
|
|
if (tagset->tags && tagset->tags[i])
|
2020-05-29 21:53:14 +08:00
|
|
|
__blk_mq_all_tag_iter(tagset->tags[i], fn, priv,
|
|
|
|
BT_TAG_ITER_STARTED);
|
2016-03-10 19:58:46 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(blk_mq_tagset_busy_iter);
|
|
|
|
|
2019-07-24 11:48:40 +08:00
|
|
|
static bool blk_mq_tagset_count_completed_rqs(struct request *rq,
|
|
|
|
void *data, bool reserved)
|
|
|
|
{
|
|
|
|
unsigned *count = data;
|
|
|
|
|
|
|
|
if (blk_mq_request_completed(rq))
|
|
|
|
(*count)++;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* blk_mq_tagset_wait_completed_request - wait until all completed req's
|
|
|
|
* complete funtion is run
|
|
|
|
* @tagset: Tag set to drain completed request
|
|
|
|
*
|
|
|
|
* Note: This function has to be run after all IO queues are shutdown
|
|
|
|
*/
|
|
|
|
void blk_mq_tagset_wait_completed_request(struct blk_mq_tag_set *tagset)
|
|
|
|
{
|
|
|
|
while (true) {
|
|
|
|
unsigned count = 0;
|
|
|
|
|
|
|
|
blk_mq_tagset_busy_iter(tagset,
|
|
|
|
blk_mq_tagset_count_completed_rqs, &count);
|
|
|
|
if (!count)
|
|
|
|
break;
|
|
|
|
msleep(5);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(blk_mq_tagset_wait_completed_request);
|
|
|
|
|
2018-09-22 04:34:46 +08:00
|
|
|
/**
|
|
|
|
* blk_mq_queue_tag_busy_iter - iterate over all requests with a driver tag
|
|
|
|
* @q: Request queue to examine.
|
|
|
|
* @fn: Pointer to the function that will be called for each request
|
|
|
|
* on @q. @fn will be called as follows: @fn(hctx, rq, @priv,
|
|
|
|
* reserved) where rq is a pointer to a request and hctx points
|
|
|
|
* to the hardware queue associated with the request. 'reserved'
|
|
|
|
* indicates whether or not @rq is a reserved request.
|
|
|
|
* @priv: Will be passed as third argument to @fn.
|
|
|
|
*
|
|
|
|
* Note: if @q->tag_set is shared with other request queues then @fn will be
|
|
|
|
* called for all requests on all queues that share that tag set and not only
|
|
|
|
* for requests associated with @q.
|
|
|
|
*/
|
2015-09-28 03:01:51 +08:00
|
|
|
void blk_mq_queue_tag_busy_iter(struct request_queue *q, busy_iter_fn *fn,
|
2014-09-14 07:40:11 +08:00
|
|
|
void *priv)
|
blk-mq: new multi-queue block IO queueing mechanism
Linux currently has two models for block devices:
- The classic request_fn based approach, where drivers use struct
request units for IO. The block layer provides various helper
functionalities to let drivers share code, things like tag
management, timeout handling, queueing, etc.
- The "stacked" approach, where a driver squeezes in between the
block layer and IO submitter. Since this bypasses the IO stack,
driver generally have to manage everything themselves.
With drivers being written for new high IOPS devices, the classic
request_fn based driver doesn't work well enough. The design dates
back to when both SMP and high IOPS was rare. It has problems with
scaling to bigger machines, and runs into scaling issues even on
smaller machines when you have IOPS in the hundreds of thousands
per device.
The stacked approach is then most often selected as the model
for the driver. But this means that everybody has to re-invent
everything, and along with that we get all the problems again
that the shared approach solved.
This commit introduces blk-mq, block multi queue support. The
design is centered around per-cpu queues for queueing IO, which
then funnel down into x number of hardware submission queues.
We might have a 1:1 mapping between the two, or it might be
an N:M mapping. That all depends on what the hardware supports.
blk-mq provides various helper functions, which include:
- Scalable support for request tagging. Most devices need to
be able to uniquely identify a request both in the driver and
to the hardware. The tagging uses per-cpu caches for freed
tags, to enable cache hot reuse.
- Timeout handling without tracking request on a per-device
basis. Basically the driver should be able to get a notification,
if a request happens to fail.
- Optional support for non 1:1 mappings between issue and
submission queues. blk-mq can redirect IO completions to the
desired location.
- Support for per-request payloads. Drivers almost always need
to associate a request structure with some driver private
command structure. Drivers can tell blk-mq this at init time,
and then any request handed to the driver will have the
required size of memory associated with it.
- Support for merging of IO, and plugging. The stacked model
gets neither of these. Even for high IOPS devices, merging
sequential IO reduces per-command overhead and thus
increases bandwidth.
For now, this is provided as a potential 3rd queueing model, with
the hope being that, as it matures, it can replace both the classic
and stacked model. That would get us back to having just 1 real
model for block devices, leaving the stacked approach to dm/md
devices (as it was originally intended).
Contributions in this patch from the following people:
Shaohua Li <shli@fusionio.com>
Alexander Gordeev <agordeev@redhat.com>
Christoph Hellwig <hch@infradead.org>
Mike Christie <michaelc@cs.wisc.edu>
Matias Bjorling <m@bjorling.me>
Jeff Moyer <jmoyer@redhat.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2013-10-24 16:20:05 +08:00
|
|
|
{
|
2015-09-28 03:01:51 +08:00
|
|
|
struct blk_mq_hw_ctx *hctx;
|
|
|
|
int i;
|
|
|
|
|
2018-08-21 15:15:04 +08:00
|
|
|
/*
|
2018-09-22 04:34:46 +08:00
|
|
|
* __blk_mq_update_nr_hw_queues() updates nr_hw_queues and queue_hw_ctx
|
|
|
|
* while the queue is frozen. So we can use q_usage_counter to avoid
|
|
|
|
* racing with it. __blk_mq_update_nr_hw_queues() uses
|
|
|
|
* synchronize_rcu() to ensure this function left the critical section
|
|
|
|
* below.
|
2018-08-21 15:15:04 +08:00
|
|
|
*/
|
2018-09-26 00:36:20 +08:00
|
|
|
if (!percpu_ref_tryget(&q->q_usage_counter))
|
2018-08-21 15:15:04 +08:00
|
|
|
return;
|
2015-09-28 03:01:51 +08:00
|
|
|
|
|
|
|
queue_for_each_hw_ctx(q, hctx, i) {
|
|
|
|
struct blk_mq_tags *tags = hctx->tags;
|
|
|
|
|
|
|
|
/*
|
2018-09-22 04:34:46 +08:00
|
|
|
* If no software queues are currently mapped to this
|
2015-09-28 03:01:51 +08:00
|
|
|
* hardware queue, there's nothing to check
|
|
|
|
*/
|
|
|
|
if (!blk_mq_hw_queue_mapped(hctx))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (tags->nr_reserved_tags)
|
2016-09-17 22:38:44 +08:00
|
|
|
bt_for_each(hctx, &tags->breserved_tags, fn, priv, true);
|
|
|
|
bt_for_each(hctx, &tags->bitmap_tags, fn, priv, false);
|
2014-05-09 23:36:49 +08:00
|
|
|
}
|
2018-09-26 00:36:20 +08:00
|
|
|
blk_queue_exit(q);
|
2014-05-09 23:36:49 +08:00
|
|
|
}
|
|
|
|
|
2016-09-17 16:28:24 +08:00
|
|
|
static int bt_alloc(struct sbitmap_queue *bt, unsigned int depth,
|
|
|
|
bool round_robin, int node)
|
2014-05-09 23:36:49 +08:00
|
|
|
{
|
2016-09-17 16:28:24 +08:00
|
|
|
return sbitmap_queue_init_node(bt, depth, -1, round_robin, GFP_KERNEL,
|
|
|
|
node);
|
2014-05-09 23:36:49 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static struct blk_mq_tags *blk_mq_init_bitmap_tags(struct blk_mq_tags *tags,
|
2015-01-24 05:18:00 +08:00
|
|
|
int node, int alloc_policy)
|
2014-05-09 23:36:49 +08:00
|
|
|
{
|
|
|
|
unsigned int depth = tags->nr_tags - tags->nr_reserved_tags;
|
2016-09-17 16:28:24 +08:00
|
|
|
bool round_robin = alloc_policy == BLK_TAG_ALLOC_RR;
|
2014-05-09 23:36:49 +08:00
|
|
|
|
2016-09-17 16:28:24 +08:00
|
|
|
if (bt_alloc(&tags->bitmap_tags, depth, round_robin, node))
|
2016-09-17 22:38:44 +08:00
|
|
|
goto free_tags;
|
2016-09-17 16:28:24 +08:00
|
|
|
if (bt_alloc(&tags->breserved_tags, tags->nr_reserved_tags, round_robin,
|
|
|
|
node))
|
2016-09-17 22:38:44 +08:00
|
|
|
goto free_bitmap_tags;
|
2014-05-09 23:36:49 +08:00
|
|
|
|
|
|
|
return tags;
|
2016-09-17 22:38:44 +08:00
|
|
|
free_bitmap_tags:
|
|
|
|
sbitmap_queue_free(&tags->bitmap_tags);
|
|
|
|
free_tags:
|
2014-05-09 23:36:49 +08:00
|
|
|
kfree(tags);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
blk-mq: new multi-queue block IO queueing mechanism
Linux currently has two models for block devices:
- The classic request_fn based approach, where drivers use struct
request units for IO. The block layer provides various helper
functionalities to let drivers share code, things like tag
management, timeout handling, queueing, etc.
- The "stacked" approach, where a driver squeezes in between the
block layer and IO submitter. Since this bypasses the IO stack,
driver generally have to manage everything themselves.
With drivers being written for new high IOPS devices, the classic
request_fn based driver doesn't work well enough. The design dates
back to when both SMP and high IOPS was rare. It has problems with
scaling to bigger machines, and runs into scaling issues even on
smaller machines when you have IOPS in the hundreds of thousands
per device.
The stacked approach is then most often selected as the model
for the driver. But this means that everybody has to re-invent
everything, and along with that we get all the problems again
that the shared approach solved.
This commit introduces blk-mq, block multi queue support. The
design is centered around per-cpu queues for queueing IO, which
then funnel down into x number of hardware submission queues.
We might have a 1:1 mapping between the two, or it might be
an N:M mapping. That all depends on what the hardware supports.
blk-mq provides various helper functions, which include:
- Scalable support for request tagging. Most devices need to
be able to uniquely identify a request both in the driver and
to the hardware. The tagging uses per-cpu caches for freed
tags, to enable cache hot reuse.
- Timeout handling without tracking request on a per-device
basis. Basically the driver should be able to get a notification,
if a request happens to fail.
- Optional support for non 1:1 mappings between issue and
submission queues. blk-mq can redirect IO completions to the
desired location.
- Support for per-request payloads. Drivers almost always need
to associate a request structure with some driver private
command structure. Drivers can tell blk-mq this at init time,
and then any request handed to the driver will have the
required size of memory associated with it.
- Support for merging of IO, and plugging. The stacked model
gets neither of these. Even for high IOPS devices, merging
sequential IO reduces per-command overhead and thus
increases bandwidth.
For now, this is provided as a potential 3rd queueing model, with
the hope being that, as it matures, it can replace both the classic
and stacked model. That would get us back to having just 1 real
model for block devices, leaving the stacked approach to dm/md
devices (as it was originally intended).
Contributions in this patch from the following people:
Shaohua Li <shli@fusionio.com>
Alexander Gordeev <agordeev@redhat.com>
Christoph Hellwig <hch@infradead.org>
Mike Christie <michaelc@cs.wisc.edu>
Matias Bjorling <m@bjorling.me>
Jeff Moyer <jmoyer@redhat.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2013-10-24 16:20:05 +08:00
|
|
|
struct blk_mq_tags *blk_mq_init_tags(unsigned int total_tags,
|
2015-01-24 05:18:00 +08:00
|
|
|
unsigned int reserved_tags,
|
|
|
|
int node, int alloc_policy)
|
blk-mq: new multi-queue block IO queueing mechanism
Linux currently has two models for block devices:
- The classic request_fn based approach, where drivers use struct
request units for IO. The block layer provides various helper
functionalities to let drivers share code, things like tag
management, timeout handling, queueing, etc.
- The "stacked" approach, where a driver squeezes in between the
block layer and IO submitter. Since this bypasses the IO stack,
driver generally have to manage everything themselves.
With drivers being written for new high IOPS devices, the classic
request_fn based driver doesn't work well enough. The design dates
back to when both SMP and high IOPS was rare. It has problems with
scaling to bigger machines, and runs into scaling issues even on
smaller machines when you have IOPS in the hundreds of thousands
per device.
The stacked approach is then most often selected as the model
for the driver. But this means that everybody has to re-invent
everything, and along with that we get all the problems again
that the shared approach solved.
This commit introduces blk-mq, block multi queue support. The
design is centered around per-cpu queues for queueing IO, which
then funnel down into x number of hardware submission queues.
We might have a 1:1 mapping between the two, or it might be
an N:M mapping. That all depends on what the hardware supports.
blk-mq provides various helper functions, which include:
- Scalable support for request tagging. Most devices need to
be able to uniquely identify a request both in the driver and
to the hardware. The tagging uses per-cpu caches for freed
tags, to enable cache hot reuse.
- Timeout handling without tracking request on a per-device
basis. Basically the driver should be able to get a notification,
if a request happens to fail.
- Optional support for non 1:1 mappings between issue and
submission queues. blk-mq can redirect IO completions to the
desired location.
- Support for per-request payloads. Drivers almost always need
to associate a request structure with some driver private
command structure. Drivers can tell blk-mq this at init time,
and then any request handed to the driver will have the
required size of memory associated with it.
- Support for merging of IO, and plugging. The stacked model
gets neither of these. Even for high IOPS devices, merging
sequential IO reduces per-command overhead and thus
increases bandwidth.
For now, this is provided as a potential 3rd queueing model, with
the hope being that, as it matures, it can replace both the classic
and stacked model. That would get us back to having just 1 real
model for block devices, leaving the stacked approach to dm/md
devices (as it was originally intended).
Contributions in this patch from the following people:
Shaohua Li <shli@fusionio.com>
Alexander Gordeev <agordeev@redhat.com>
Christoph Hellwig <hch@infradead.org>
Mike Christie <michaelc@cs.wisc.edu>
Matias Bjorling <m@bjorling.me>
Jeff Moyer <jmoyer@redhat.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2013-10-24 16:20:05 +08:00
|
|
|
{
|
|
|
|
struct blk_mq_tags *tags;
|
|
|
|
|
|
|
|
if (total_tags > BLK_MQ_TAG_MAX) {
|
|
|
|
pr_err("blk-mq: tag depth too large\n");
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
tags = kzalloc_node(sizeof(*tags), GFP_KERNEL, node);
|
|
|
|
if (!tags)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
tags->nr_tags = total_tags;
|
|
|
|
tags->nr_reserved_tags = reserved_tags;
|
|
|
|
|
2015-01-24 05:18:00 +08:00
|
|
|
return blk_mq_init_bitmap_tags(tags, node, alloc_policy);
|
blk-mq: new multi-queue block IO queueing mechanism
Linux currently has two models for block devices:
- The classic request_fn based approach, where drivers use struct
request units for IO. The block layer provides various helper
functionalities to let drivers share code, things like tag
management, timeout handling, queueing, etc.
- The "stacked" approach, where a driver squeezes in between the
block layer and IO submitter. Since this bypasses the IO stack,
driver generally have to manage everything themselves.
With drivers being written for new high IOPS devices, the classic
request_fn based driver doesn't work well enough. The design dates
back to when both SMP and high IOPS was rare. It has problems with
scaling to bigger machines, and runs into scaling issues even on
smaller machines when you have IOPS in the hundreds of thousands
per device.
The stacked approach is then most often selected as the model
for the driver. But this means that everybody has to re-invent
everything, and along with that we get all the problems again
that the shared approach solved.
This commit introduces blk-mq, block multi queue support. The
design is centered around per-cpu queues for queueing IO, which
then funnel down into x number of hardware submission queues.
We might have a 1:1 mapping between the two, or it might be
an N:M mapping. That all depends on what the hardware supports.
blk-mq provides various helper functions, which include:
- Scalable support for request tagging. Most devices need to
be able to uniquely identify a request both in the driver and
to the hardware. The tagging uses per-cpu caches for freed
tags, to enable cache hot reuse.
- Timeout handling without tracking request on a per-device
basis. Basically the driver should be able to get a notification,
if a request happens to fail.
- Optional support for non 1:1 mappings between issue and
submission queues. blk-mq can redirect IO completions to the
desired location.
- Support for per-request payloads. Drivers almost always need
to associate a request structure with some driver private
command structure. Drivers can tell blk-mq this at init time,
and then any request handed to the driver will have the
required size of memory associated with it.
- Support for merging of IO, and plugging. The stacked model
gets neither of these. Even for high IOPS devices, merging
sequential IO reduces per-command overhead and thus
increases bandwidth.
For now, this is provided as a potential 3rd queueing model, with
the hope being that, as it matures, it can replace both the classic
and stacked model. That would get us back to having just 1 real
model for block devices, leaving the stacked approach to dm/md
devices (as it was originally intended).
Contributions in this patch from the following people:
Shaohua Li <shli@fusionio.com>
Alexander Gordeev <agordeev@redhat.com>
Christoph Hellwig <hch@infradead.org>
Mike Christie <michaelc@cs.wisc.edu>
Matias Bjorling <m@bjorling.me>
Jeff Moyer <jmoyer@redhat.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2013-10-24 16:20:05 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void blk_mq_free_tags(struct blk_mq_tags *tags)
|
|
|
|
{
|
2016-09-17 22:38:44 +08:00
|
|
|
sbitmap_queue_free(&tags->bitmap_tags);
|
|
|
|
sbitmap_queue_free(&tags->breserved_tags);
|
blk-mq: new multi-queue block IO queueing mechanism
Linux currently has two models for block devices:
- The classic request_fn based approach, where drivers use struct
request units for IO. The block layer provides various helper
functionalities to let drivers share code, things like tag
management, timeout handling, queueing, etc.
- The "stacked" approach, where a driver squeezes in between the
block layer and IO submitter. Since this bypasses the IO stack,
driver generally have to manage everything themselves.
With drivers being written for new high IOPS devices, the classic
request_fn based driver doesn't work well enough. The design dates
back to when both SMP and high IOPS was rare. It has problems with
scaling to bigger machines, and runs into scaling issues even on
smaller machines when you have IOPS in the hundreds of thousands
per device.
The stacked approach is then most often selected as the model
for the driver. But this means that everybody has to re-invent
everything, and along with that we get all the problems again
that the shared approach solved.
This commit introduces blk-mq, block multi queue support. The
design is centered around per-cpu queues for queueing IO, which
then funnel down into x number of hardware submission queues.
We might have a 1:1 mapping between the two, or it might be
an N:M mapping. That all depends on what the hardware supports.
blk-mq provides various helper functions, which include:
- Scalable support for request tagging. Most devices need to
be able to uniquely identify a request both in the driver and
to the hardware. The tagging uses per-cpu caches for freed
tags, to enable cache hot reuse.
- Timeout handling without tracking request on a per-device
basis. Basically the driver should be able to get a notification,
if a request happens to fail.
- Optional support for non 1:1 mappings between issue and
submission queues. blk-mq can redirect IO completions to the
desired location.
- Support for per-request payloads. Drivers almost always need
to associate a request structure with some driver private
command structure. Drivers can tell blk-mq this at init time,
and then any request handed to the driver will have the
required size of memory associated with it.
- Support for merging of IO, and plugging. The stacked model
gets neither of these. Even for high IOPS devices, merging
sequential IO reduces per-command overhead and thus
increases bandwidth.
For now, this is provided as a potential 3rd queueing model, with
the hope being that, as it matures, it can replace both the classic
and stacked model. That would get us back to having just 1 real
model for block devices, leaving the stacked approach to dm/md
devices (as it was originally intended).
Contributions in this patch from the following people:
Shaohua Li <shli@fusionio.com>
Alexander Gordeev <agordeev@redhat.com>
Christoph Hellwig <hch@infradead.org>
Mike Christie <michaelc@cs.wisc.edu>
Matias Bjorling <m@bjorling.me>
Jeff Moyer <jmoyer@redhat.com>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2013-10-24 16:20:05 +08:00
|
|
|
kfree(tags);
|
|
|
|
}
|
|
|
|
|
2017-01-20 01:59:07 +08:00
|
|
|
int blk_mq_tag_update_depth(struct blk_mq_hw_ctx *hctx,
|
|
|
|
struct blk_mq_tags **tagsptr, unsigned int tdepth,
|
|
|
|
bool can_grow)
|
2014-05-21 01:49:02 +08:00
|
|
|
{
|
2017-01-20 01:59:07 +08:00
|
|
|
struct blk_mq_tags *tags = *tagsptr;
|
|
|
|
|
|
|
|
if (tdepth <= tags->nr_reserved_tags)
|
2014-05-21 01:49:02 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/*
|
2017-01-20 01:59:07 +08:00
|
|
|
* If we are allowed to grow beyond the original size, allocate
|
|
|
|
* a new set of tags before freeing the old one.
|
2014-05-21 01:49:02 +08:00
|
|
|
*/
|
2017-01-20 01:59:07 +08:00
|
|
|
if (tdepth > tags->nr_tags) {
|
|
|
|
struct blk_mq_tag_set *set = hctx->queue->tag_set;
|
|
|
|
struct blk_mq_tags *new;
|
|
|
|
bool ret;
|
|
|
|
|
|
|
|
if (!can_grow)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We need some sort of upper limit, set it high enough that
|
|
|
|
* no valid use cases should require more.
|
|
|
|
*/
|
|
|
|
if (tdepth > 16 * BLKDEV_MAX_RQ)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2018-08-02 18:23:26 +08:00
|
|
|
new = blk_mq_alloc_rq_map(set, hctx->queue_num, tdepth,
|
|
|
|
tags->nr_reserved_tags);
|
2017-01-20 01:59:07 +08:00
|
|
|
if (!new)
|
|
|
|
return -ENOMEM;
|
|
|
|
ret = blk_mq_alloc_rqs(set, new, hctx->queue_num, tdepth);
|
|
|
|
if (ret) {
|
|
|
|
blk_mq_free_rq_map(new);
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
|
|
|
blk_mq_free_rqs(set, *tagsptr, hctx->queue_num);
|
|
|
|
blk_mq_free_rq_map(*tagsptr);
|
|
|
|
*tagsptr = new;
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Don't need (or can't) update reserved tags here, they
|
|
|
|
* remain static and should never need resizing.
|
|
|
|
*/
|
2018-08-02 18:23:26 +08:00
|
|
|
sbitmap_queue_resize(&tags->bitmap_tags,
|
|
|
|
tdepth - tags->nr_reserved_tags);
|
2017-01-20 01:59:07 +08:00
|
|
|
}
|
2016-09-17 22:38:44 +08:00
|
|
|
|
2014-05-21 01:49:02 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-10-30 21:45:11 +08:00
|
|
|
/**
|
|
|
|
* blk_mq_unique_tag() - return a tag that is unique queue-wide
|
|
|
|
* @rq: request for which to compute a unique tag
|
|
|
|
*
|
|
|
|
* The tag field in struct request is unique per hardware queue but not over
|
|
|
|
* all hardware queues. Hence this function that returns a tag with the
|
|
|
|
* hardware context index in the upper bits and the per hardware queue tag in
|
|
|
|
* the lower bits.
|
|
|
|
*
|
|
|
|
* Note: When called for a request that is queued on a non-multiqueue request
|
|
|
|
* queue, the hardware context index is set to zero.
|
|
|
|
*/
|
|
|
|
u32 blk_mq_unique_tag(struct request *rq)
|
|
|
|
{
|
2018-10-30 05:06:13 +08:00
|
|
|
return (rq->mq_hctx->queue_num << BLK_MQ_UNIQUE_TAG_BITS) |
|
2014-10-30 21:45:11 +08:00
|
|
|
(rq->tag & BLK_MQ_UNIQUE_TAG_MASK);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(blk_mq_unique_tag);
|