On Thursday, February 17, 2011 at 11:13 PM, Sage Weil wrote: On Thu, 17 Feb 2011, Jim Schutt wrote: > > Why should it take 28 seconds to add a new timer event? > > Huh.. that is pretty weird. I see multiple sync in there, too, so it's > not like something was somehow blocking on a btrfs commit. > > Anybody else have ideas? :/ > > sage I must be missing something but I looked through that code (it's short), and as far as I can tell there's no blocking code anywhere at all. The only time it takes any locks is when grabbing the dout locks for those debug prints; it doesn't initiate any file IO or wait for any completions; it just does a few map ops and g_time.now() arithmetic. It does signal Timer::cond at the end of the timer insert, but the only things waiting on that should be the timer thread itself, which needs to get back the osd_lock, which is currently locked so that shouldn't be a problem either! -Greg -- 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
