From owner-freebsd-arch@FreeBSD.ORG Tue Nov 14 17:26:50 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 4949316A415 for ; Tue, 14 Nov 2006 17:26:50 +0000 (UTC) (envelope-from jdp@polstra.com) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A2F243D79 for ; Tue, 14 Nov 2006 17:26:46 +0000 (GMT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [64.81.189.67]) by blake.polstra.com (8.13.6/8.13.6) with ESMTP id kAEHQj8i071917; Tue, 14 Nov 2006 09:26:45 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <7105.1163451221@critter.freebsd.dk> Date: Tue, 14 Nov 2006 09:26:45 -0800 (PST) From: John Polstra To: Poul-Henning Kamp 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 17:26:50 -0000 On 13-Nov-2006 Poul-Henning Kamp wrote: > > A number of problems have been identified with our current callout > code and I have been thinking about and discussed various aspects > with people during the EuroBSDcon2007 conference. > > A lot of people are interested in this, so here is a quick sketch > of what I'm thinking about: > > > The Problems > ------------ > > 1. We need better resolution than a periodic "hz" clock can give us. > Highspeed networking, gaming servers and other real-time apps want > this. > > 2. We "pollute" our call-wheel with tons of callouts that we know are > unlikely to happen. > > 3. We have many operations on the callout wheel because certain > callouts gets rearmed for later in the future. (TCP keepalives). > > 4. We execute all callouts on one CPU only. > > 5. Most of the specified timeouts are bogus, because of the imprecision > inheret in the current 1/hz method of scheduling them. > > and a number of other issues. > > > The proposed API > ---------------- I like the proposed API. FWIW, the problems you listed that are most important to me are #4 and #1. Inexpensive automatic rearming for periodic timeouts is also important. John