Date: Tue, 14 Nov 2006 16:25:56 +0100 From: Andre Oppermann <andre@freebsd.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: arch@freebsd.org Subject: Re: a proposed callout API Message-ID: <4559E004.6050204@freebsd.org> In-Reply-To: <7105.1163451221@critter.freebsd.dk> References: <7105.1163451221@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp wrote: > The idea behind this (untried) scheme for the long callouts, is to > distribute the callouts somewhat evenly in the lists, while maintaining > only the relevant entries in the first list, the point being that > most of them (TCP keepalive, CAM etc) will never happen, so spending > time sorting them more than necessary is pointless. Obviously, > this algorithm needs to be tested in practice and tuned/changed/discared > depending on the results. TCP maintains a number of timers per connection of which most never ever fire. I have working code that manages the timers within TCP and registers only the next upcoming with the callout mechanism. This avoids a lot of pointless churn in the callout wheels. Nonetheless one callout is disabled/ rearmed per packet sent/received. A majority of those again will never fire and instead rearm on the next packet. A non-profiled guess makes TCP the #1 churner in the whole callout mechanism. Firing TCP callouts may do significant work which could easily be run in parallel for any number of TCP sessions. For TCP we may want to insert an abstraction where the callout mechanism kicks a taskqueue instead of running the callout itself. There we may have a number (=ncpu) of worker threads services this taskqueue. In TCP we also may hit a number of cases where the callout fires at the time a packet for that connection comes in. If the callout finds the tcpcb already locked it simply may discard this callout right away instead of (busy) waiting as all timer stuff and rearming will already happen while it is locked. However keep in mind these are all educated guesses but not hard facts from profiling on real machines. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4559E004.6050204>