/openbmc/linux/drivers/target/iscsi/ |
H A D | iscsi_target_device.c | 109e2381 Thu Jul 23 16:53:32 CDT 2015 Roland Dreier <roland@purestorage.com> 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> 109e2381 Thu Jul 23 16:53:32 CDT 2015 Roland Dreier <roland@purestorage.com> 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>
|
H A D | iscsi_target_tmr.c | 109e2381 Thu Jul 23 16:53:32 CDT 2015 Roland Dreier <roland@purestorage.com> 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> 109e2381 Thu Jul 23 16:53:32 CDT 2015 Roland Dreier <roland@purestorage.com> 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>
|
H A D | iscsi_target_nego.c | 109e2381 Thu Jul 23 16:53:32 CDT 2015 Roland Dreier <roland@purestorage.com> 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> 109e2381 Thu Jul 23 16:53:32 CDT 2015 Roland Dreier <roland@purestorage.com> 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>
|
H A D | iscsi_target_configfs.c | 109e2381 Thu Jul 23 16:53:32 CDT 2015 Roland Dreier <roland@purestorage.com> 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> 109e2381 Thu Jul 23 16:53:32 CDT 2015 Roland Dreier <roland@purestorage.com> 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>
|
H A D | iscsi_target_util.c | 109e2381 Thu Jul 23 16:53:32 CDT 2015 Roland Dreier <roland@purestorage.com> 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> 109e2381 Thu Jul 23 16:53:32 CDT 2015 Roland Dreier <roland@purestorage.com> 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>
|
H A D | iscsi_target_login.c | 109e2381 Thu Jul 23 16:53:32 CDT 2015 Roland Dreier <roland@purestorage.com> 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> 109e2381 Thu Jul 23 16:53:32 CDT 2015 Roland Dreier <roland@purestorage.com> 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>
|
H A D | iscsi_target.c | 109e2381 Thu Jul 23 16:53:32 CDT 2015 Roland Dreier <roland@purestorage.com> 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> 109e2381 Thu Jul 23 16:53:32 CDT 2015 Roland Dreier <roland@purestorage.com> 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>
|
/openbmc/linux/include/target/iscsi/ |
H A D | iscsi_target_core.h | 109e2381 Thu Jul 23 16:53:32 CDT 2015 Roland Dreier <roland@purestorage.com> 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> 109e2381 Thu Jul 23 16:53:32 CDT 2015 Roland Dreier <roland@purestorage.com> 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>
|