path: root/include/target
diff options
authorRoland Dreier <roland@purestorage.com>2015-07-23 14:53:32 -0700
committerNicholas Bellinger <nab@linux-iscsi.org>2015-08-02 23:11:52 -0700
commit109e2381749c1cfd94a0d22b2b54142539024973 (patch)
tree9695ecd3738a7bad43edcca4eb641339e7a30060 /include/target
parent24c7d6c7316c72301bf8ecfc1189fd476176fd75 (diff)
target: Drop iSCSI use of mutex around max_cmd_sn increment
In a performance profile, taking a mutex in iscsit_increment_maxcmdsn() shows up very high. However taking a mutex around "sess->max_cmd_sn += 1" seems pretty silly: we're not serializing against other contexts in any useful way. I did a quick audit and there don't appear to be any other places that use max_cmd_sn within the mutex more than once, so this lock can't be providing any useful serialization. (Get correct values for logging - fix whitespace damage) Signed-off-by: Roland Dreier <roland@purestorage.com> Signed-off-by: Spencer Baugh <sbaugh@catern.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Diffstat (limited to 'include/target')
1 files changed, 1 insertions, 1 deletions
diff --git a/include/target/iscsi/iscsi_target_core.h b/include/target/iscsi/iscsi_target_core.h
index ab465858f462..d4616ef12e04 100644
--- a/include/target/iscsi/iscsi_target_core.h
+++ b/include/target/iscsi/iscsi_target_core.h
@@ -637,7 +637,7 @@ struct iscsi_session {
/* session wide counter: expected command sequence number */
u32 exp_cmd_sn;
/* session wide counter: maximum allowed command sequence number */
- u32 max_cmd_sn;
+ atomic_t max_cmd_sn;
struct list_head sess_ooo_cmdsn_list;
/* LIO specific session ID */

Privacy Policy