| 95df4e0d | 20-May-2024 |
Shuhei Matsumoto <smatsumoto@nvidia.com> |
bdev: Fix a race bug between unregistration and QoS poller
There was a bug that bdev_channel_poll_qos() called spdk_for_each_channel()
after spdk_io_device_unregister() is called for a bdev.
This o
bdev: Fix a race bug between unregistration and QoS poller
There was a bug that bdev_channel_poll_qos() called spdk_for_each_channel()
after spdk_io_device_unregister() is called for a bdev.
This occurred in the following sequence.
- There was a bdev and a channel for it.
- QoS was enabled and started.
- spdk_bdev_unregister() was called. However, there was a open descriptor.
Hence, remove notification was sent and unregistration was pending.
- Receiving a event notification, spdk_put_io_channel() and spdk_bdev_close() were
called. In spdk_bdev_close(), the existing QoS was unbound and a message was sent
to it, and then the pending spdk_io_device_unregister() was finally executed.
- If bdev_channel_poll_qos() was executed before the message was processed,
bdev_channel_poll_qos() called spdk_bdev_for_each_channel() and hit assert().
The fix is in this case bdev_channel_poll_qos() returned immediately because QoS
is not enabled. bdev_qos_destroy() created a new disabled QoS and swapped it with
the existing QoS.
Fixes issue #3367
Signed-off-by: Shuhei Matsumoto <smatsumoto@nvidia.com>
Change-Id: I8d4525c9206f7f395ad4ba4a706fed59addc3fe8
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/23219
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Konrad Sztyber <konrad.sztyber@intel.com>
Community-CI: Mellanox Build Bot
Reviewed-by: Jim Harris <jim.harris@samsung.com>
show more ...
|
| 055de83a | 02-Mar-2023 |
Anton Nayshtut <anayshtut@nvidia.com> |
bdev: multiple QoS queues with atomic-based QoS quota
Here's a comparison of the legacy and the atomic-based QoS.
Tested with bdevperf + 1 null or malloc bdev. When the Qos is enabled
the limit set
bdev: multiple QoS queues with atomic-based QoS quota
Here's a comparison of the legacy and the atomic-based QoS.
Tested with bdevperf + 1 null or malloc bdev. When the Qos is enabled
the limit set to the value higher than the setup is capable of achieving
(900.000.000 IOPs).
| bdev | CPU | No QoS | Legacy QoS | Atomic QoS | LP | AP |
| | Mask | | (IOPS) | (IOPS) | (%) | (%) |
|--------|------|--------------|------------|-------------|-----|-----|
| null | 1 | 10807210.39 | 8720802.93 | 8883633.79 | 19 | 18 |
| null | 3 | 21065293.41 | 7798114.51 | 8605514.14 | 63 | 59 |
| null | 7 | 31941220.35 | 8026022.82 | 11057120.85 | 75 | 65 |
| null | F | 42510017.40 | 7655892.00 | 11832259.16 | 82 | 72 |
| null | FF | 80864836.44 | 7598421.52 | 13096449.71 | 91 | 84 |
| null | FFF | 121780455.70 | 7609117.22 | 11030412.77 | 94 | 91 |
| null | FFFF | 162071300.70 | 7558077.12 | 10826030.57 | 95 | 93 |
| malloc | 1 | 1948096.14 | 1863817.94 | 1881245.75 | 4 | 3 |
| malloc | 3 | 3803549.11 | 2068897.67 | 3155528.57 | 46 | 17 |
| malloc | 7 | 5593798.24 | 2227017.22 | 4387343.78 | 60 | 22 |
| malloc | F | 7231720.95 | 2281762.70 | 5797832.38 | 68 | 20 |
| malloc | FF | 12070891.12 | 2614674.11 | 9690367.72 | 78 | 20 |
| malloc | FFF | 13989626.48 | 2630881.18 | 12840411.99 | 81 | 8 |
| malloc | FFFF | 14405443.97 | 2600775.13 | 9992956.98 | 82 | 31 |
Change-Id: Ia91706b761e085b4231a2fb9a08565c305735b7d
Signed-off-by: Anton Nayshtut <anayshtut@nvidia.com>
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/18914
Reviewed-by: Ben Walker <ben@nvidia.com>
Community-CI: Mellanox Build Bot
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Reviewed-by: Jim Harris <jim.harris@samsung.com>
show more ...
|
| 04c222f2 | 15-Feb-2023 |
Konrad Sztyber <konrad.sztyber@intel.com> |
bdev: accel sequence support for read requests
This patch enables passing accel sequence for read requests. The
handling is pretty similar to writes, but the sequence is executed after
a request is
bdev: accel sequence support for read requests
This patch enables passing accel sequence for read requests. The
handling is pretty similar to writes, but the sequence is executed after
a request is completed by a bdev module.
Signed-off-by: Konrad Sztyber <konrad.sztyber@intel.com>
Change-Id: I79fd7d4873265c81a9f4a66362634a1c4901d0c9
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/16975
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Community-CI: Mellanox Build Bot
Reviewed-by: Aleksey Marchuk <alexeymar@nvidia.com>
show more ...
|
| 22c0e978 | 14-Feb-2023 |
Konrad Sztyber <konrad.sztyber@intel.com> |
bdev: accel sequence support for write requests
It is now possible to submit a write request with a sequence of accel
operations that need to be executed before actually writing the data.
Such requ
bdev: accel sequence support for write requests
It is now possible to submit a write request with a sequence of accel
operations that need to be executed before actually writing the data.
Such requests will be directly passed to a bdev module (so that it can
append subsequent operations to an accel sequence) if that bdev supports
accel sequences and the request doesn't need to be split. If either of
these conditions are not met, bdev layer will execute all the
accumulated accel operations before passing the request to a bdev
module.
The reason for not submitting split IOs with an accel sequence is that
we would need to split that accel sequence too. Currently, there's no
such functionality in accel, so we treat this case in the same way as if
the underlying bdev module didn't support accel sequences (it's executed
before bdev_io is split).
Signed-off-by: Konrad Sztyber <konrad.sztyber@intel.com>
Change-Id: I66c53b3a1a87a35ea2687292206c899f80aaed4a
Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/16974
Reviewed-by: Ben Walker <benjamin.walker@intel.com>
Tested-by: SPDK CI Jenkins <sys_sgci@intel.com>
Community-CI: Mellanox Build Bot
Reviewed-by: Aleksey Marchuk <alexeymar@nvidia.com>
show more ...
|