Searched hist:af1dd7ff (Results 1 – 1 of 1) sorted by relevance
| /openbmc/linux/drivers/target/ |
| H A D | target_core_user.c | af1dd7ff Tue Nov 28 12:40:39 CST 2017 Mike Christie <mchristi@redhat.com> tcmu: don't block submitting context for block waits
This patch has tcmu internally queue cmds if its ring buffer
is full. It also makes the TCMU_GLOBAL_MAX_BLOCKS limit a
hint instead of a hard limit, so we do not have to add any
new locks/atomics in the main IO path except when IO is not
running.
This fixes the following bugs:
1. We cannot sleep from the submitting context because it might be
called from a target recv context. This results in transport level
commands timing out. For example if the ring is full, we would
sleep, and a iscsi initiator would send a iscsi ping/nop which
times out because the target's recv thread is sleeping here.
2. Devices were not fairly scheduled to run when they hit the global
limit so they could time out waiting for ring space while others
got run.
Signed-off-by: Mike Christie <mchristi@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
af1dd7ff Tue Nov 28 12:40:39 CST 2017 Mike Christie <mchristi@redhat.com> tcmu: don't block submitting context for block waits
This patch has tcmu internally queue cmds if its ring buffer
is full. It also makes the TCMU_GLOBAL_MAX_BLOCKS limit a
hint instead of a hard limit, so we do not have to add any
new locks/atomics in the main IO path except when IO is not
running.
This fixes the following bugs:
1. We cannot sleep from the submitting context because it might be
called from a target recv context. This results in transport level
commands timing out. For example if the ring is full, we would
sleep, and a iscsi initiator would send a iscsi ping/nop which
times out because the target's recv thread is sleeping here.
2. Devices were not fairly scheduled to run when they hit the global
limit so they could time out waiting for ring space while others
got run.
Signed-off-by: Mike Christie <mchristi@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
|