Doing __schedule_delayed() in the hunting branch is pointless, as the
tick will have already been scheduled by then.
What we need to do instead is *reschedule* it in the !hunting branch,
after reopen_session() changes hunt_mult, which affects the delay.
This helps with spacing out connection attempts and avoiding things
like two back-to-back attempts followed by a longer period of waiting
around.
Signed-off-by: Ilya Dryomov <idryomov@xxxxxxxxx>
---
net/ceph/mon_client.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/ceph/mon_client.c b/net/ceph/mon_client.c
index 816fb813a336..a2b45cf79dca 100644
--- a/net/ceph/mon_client.c
+++ b/net/ceph/mon_client.c
@@ -222,8 +222,8 @@ static void __schedule_delayed(struct ceph_mon_client *monc)
delay = CEPH_MONC_PING_INTERVAL;
dout("__schedule_delayed after %lu\n", delay);
- schedule_delayed_work(&monc->delayed_work,
- round_jiffies_relative(delay));
+ mod_delayed_work(system_wq, &monc->delayed_work,
+ round_jiffies_relative(delay));
}
const char *ceph_sub_str[] = {
@@ -1166,9 +1166,9 @@ static void mon_fault(struct ceph_connection *con)
if (!monc->hunting) {
dout("%s hunting for new mon\n", __func__);
reopen_session(monc);
- } else {
- /* already hunting, let's wait a bit */
__schedule_delayed(monc);
+ } else {
+ dout("%s already hunting\n", __func__);
}
out:
mutex_unlock(&monc->mutex);
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
