Reviewed-by: Sage Weil <[email protected]>
On Tue, 9 Oct 2012, Alex Elder wrote: > Both ceph_fault() and con_work() include handling for imposing a > delay before doing further processing on a faulted connection. > The latter is used only if ceph_fault() is unable to. > > Instead, just let con_work() always be responsible for implementing > the delay. After setting up the delay value, set the BACKOFF flag > on the connection unconditionally and call queue_con() to ensure > con_work() will get called to handle it. > > Signed-off-by: Alex Elder <[email protected]> > --- > net/ceph/messenger.c | 20 ++------------------ > 1 file changed, 2 insertions(+), 18 deletions(-) > > diff --git a/net/ceph/messenger.c b/net/ceph/messenger.c > index ece06bc..9170c20 100644 > --- a/net/ceph/messenger.c > +++ b/net/ceph/messenger.c > @@ -2398,24 +2398,8 @@ static void ceph_fault(struct ceph_connection *con) > con->delay = BASE_DELAY_INTERVAL; > else if (con->delay < MAX_DELAY_INTERVAL) > con->delay *= 2; > - con->ops->get(con); > - if (queue_delayed_work(ceph_msgr_wq, &con->work, > - round_jiffies_relative(con->delay))) { > - dout("fault queued %p delay %lu\n", con, con->delay); > - } else { > - con->ops->put(con); > - dout("fault failed to queue %p delay %lu, backoff\n", > - con, con->delay); > - /* > - * In many cases we see a socket state change > - * while con_work is running and end up > - * queuing (non-delayed) work, such that we > - * can't backoff with a delay. Set a flag so > - * that when con_work restarts we schedule the > - * delay then. > - */ > - set_bit(CON_FLAG_BACKOFF, &con->flags); > - } > + set_bit(CON_FLAG_BACKOFF, &con->flags); > + queue_con(con); > } > > out_unlock: > -- > 1.7.9.5 > > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to [email protected] > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
