Date: Sun, 3 Feb 2002 22:17:00 +0000 (GMT) From: Mike Silbersack <silby@silby.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Alfred Perlstein <bright@mu.org>, Luigi Rizzo <rizzo@icir.org>, Storms of Perfection <gary@outloud.org>, <thierry@herbelot.com>, <replicator@ngs.ru>, <hackers@FreeBSD.org> Subject: Re: Clock Granularity (kernel option HZ) Message-ID: <20020203220958.Q13287-100000@patrocles.silby.com> In-Reply-To: <3C5A8290.216BB28C@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 1 Feb 2002, Terry Lambert wrote: > I guess you are talking the LRP stuff. > > I was just talking about the processing at NETISR as a > result of a higher HZ causing a higher softintr run > frequency. Interesting; I hadn't considered that scheduling could have an effect on performance, but that does make sense on a heavily loaded system. > Really, the timer code that TCP uses is all bogus for a > large number of connections, and upping the clock wheel > size doesn't gain you nearly as much as interval specific > lists which only have to process until the intended time > to fire is later than "now". The clock stuff as it is > has to traverse the entire chain, because it can't know > that the firing of the timer after the current one is later > than the current one (i.e. intervals of 1 second and one > hour can end up in the same wheel bucket, because it is, in > effect, an unsorted modular timer, and inserting sorted for > more than one or two intervals is an O(N) problem). > > -- Terry I was looking at the timer implementation a few weeks ago and pondering if it could be improved as well. I think it's quite clever if you're dealing with a quantity of timers < 1000 or so, but it looks like it could be more optimal when used with the quantity of timers we have these days. Did you attempt to combine the various tcp timers so that there would be one callout per socket? I think it would be a pretty easy task; just store the various timers inside each socket, and only set a callout for the soonest to wake one. Upon wakeup, quickly check them all. That would reduce the total number of events in the callout wheel for one, and might help with the hash function aliasing long-term events such as keepalives into the current time. (I'm assuming that the retransmission and other short-term timers do a good job of keeping themselves just ahead of the clockhand that they aren't falsely checked.) Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020203220958.Q13287-100000>