Date: Sun, 30 Jan 2005 19:19:47 -0600 (CST) From: Mike Silbersack <silby@silby.com> To: Robert Watson <rwatson@FreeBSD.org> Cc: Colin Percival <cperciva@freebsd.org> Subject: Re: tcp_isn_tick() / dummynet() callout madness ? Message-ID: <20050130191410.R62670@odysseus.silby.com> In-Reply-To: <Pine.NEB.3.96L.1050130225100.15336M-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1050130225100.15336M-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 30 Jan 2005, Robert Watson wrote: > On Sun, 30 Jan 2005, Mike Silbersack wrote: > >> change to the callout API? Just a few places in the kernel account for >> most of the use of callouts, so even if a rewrite of those would be >> necessary, it should pay off. > > Well, part of the problem is that many callouts always re-register, and > right now they're forced to pay a penalty for it. I almost wonder if we > shouldn't add a new flag or method to swap the costs: register a recurring > callout every (x) ticks, and you pay a cost to unregister it if the flag > is set, and the callout is otherwise automatically rescheduled. > > Robert N M Watson That sounds worthwhile. For things like tcp_isn_tick, it'd be perfect. For the per-socket TCP timers, here's what I've been pondering for a while. Right now, we use seperate callouts for retransmit, 2msl, keepalive, delayed ack, etc. If we made the code just a little bit smarter (and that would be easy with some quick macros), we could bring each socket down to a single callout. That callout, whenever triggered, would look through the per-socket data and see which of the different timers was the one that just fired, and run it. Since the keepalive callout is almost never fired, but always rescheduled, that'd be a big win. This could be used with your auto-reschedule idea; perhaps the way auto-reschedule would work is that each callout has a next callout time set. So, suppose that we have a delayed ack timeout happening in 50ms, and a potential retransmit timeout happening in 4 seconds. We'd set the per-socket callout for 50ms, with a next time of 4 seconds. When the callout fires, it'll be rescheduled for 3.95 seconds from now, and if that's wrong, we'll just have to incur the cost of rescheduling it. But, in the case of the next time being correct, that would be much more efficient. Mike "Silby" Silbersack
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050130191410.R62670>