Date: Tue, 23 Sep 1997 08:52:51 -0600 (MDT) From: Nate Williams <nate@mt.sri.com> To: Julian Elischer <julian@whistle.com> Cc: "Justin T. Gibbs" <gibbs@plutotech.com>, Terry Lambert <tlambert@primenet.com>, nate@mt.sri.com, bde@zeta.org.au, current@freebsd.org Subject: new timeout routines Message-ID: <199709231452.IAA07122@rocky.mt.sri.com> In-Reply-To: <Pine.BSF.3.95.970923013950.9006B-100000@current1.whistle.com> References: <199709230630.AAA13505@pluto.plutotech.com> <Pine.BSF.3.95.970923013950.9006B-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > >> >Queue the entry for ordered insertion when timeout() is called, but > > >> >delay the ordered insertion until softclock(). > > his was one of the things I have been wondering about. > if each spoke of the wheel had an orderd and an unordered queue, > then items would USUALLY be removed before their > bucket was accessed. Any remaining ones could be > moved to the ordered "long term" queue. The issue is will the entries in the "long term" queue now be accessed enough times to make inserting them in an ordered list to make it wortwhile to insert them into the ordered list. We'd be now getting a much smaller speedup, since softclock() would still have to walk the un-ordered list (which would contain the majority of the items), and now we're taken some (how many?) of those items off the unordered list and put them on an ordered list. My gut feeling is that if we don't take the hit up front (at timeout), then don't bother at all since we're only getting a minimal gain. > They could be inserted into a timeout queue not disimilar to that we > already run. The point is that there are several distinct usage models for > the timeout facility. They have differnt characteristics.. > HARDWARE FAILURE TIMEOUTS: nearly ALWAYS expected to be removed very > quickly. Ordering these is a complete waste of time. But, they will tend to go away. > PERIODIC EVENTS: nearly always time out. These tend to be of duration of > a large fraction of a second. Possibly it might be more efficient > to have a different mechanism for periodic events. > > LONG TERM EVENT timing: These tend to be longer in duration, but are not > recuring. These will be hit by the softclock several times. This > could be considered a waste of resources, if we could hold them off for a > while we should. How many of the bottom 2 types are there, and will searching for them in an un-ordered list make *that* much difference given the number of first type that are on an un-ordered list. > If the wheel is very sparcely populated it doesn't gain much, but then > again it isn't that much more expensive than what you have now. It doesn't gain much, but neither does it cost much. Now there's some logic. :) > When the wheel get's heavily populated, or when there are a lot of > long-term entries it saves time. I suspect that when the wheels' heavily populated, most of the entries will be of the short-term type, so ordering the long-term values is a non-win. > These were my thoughts while reading the paper. I was a little > dissapointed that you didn't implement the compatible interface that > they originally wrote. Now, this is something I don't understand. Why the need for the 'cookies' in the drivers, since I don't see what it gains us? (Time to go re-read the code and paper again.) Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709231452.IAA07122>