From owner-freebsd-arch@FreeBSD.ORG Tue Nov 14 15:27:01 2006 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3173B16A4ED for ; Tue, 14 Nov 2006 15:27:01 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6159F43E0E for ; Tue, 14 Nov 2006 15:25:58 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 5669 invoked from network); 14 Nov 2006 15:18:38 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Nov 2006 15:18:38 -0000 Message-ID: <4559E004.6050204@freebsd.org> Date: Tue, 14 Nov 2006 16:25:56 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Poul-Henning Kamp References: <7105.1163451221@critter.freebsd.dk> In-Reply-To: <7105.1163451221@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org Subject: Re: a proposed callout API X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2006 15:27:01 -0000 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