From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 07:16:15 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 686DD16A4CF for ; Mon, 31 Jan 2005 07:16:15 +0000 (GMT) Received: from relay.pair.com (relay00.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 8F0BF43D46 for ; Mon, 31 Jan 2005 07:16:14 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 23868 invoked from network); 31 Jan 2005 07:16:13 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 31 Jan 2005 07:16:13 -0000 X-pair-Authenticated: 209.68.2.70 Date: Mon, 31 Jan 2005 01:16:12 -0600 (CST) From: Mike Silbersack To: Poul-Henning Kamp In-Reply-To: <84537.1107153288@critter.freebsd.dk> Message-ID: <20050131011241.F64157@odysseus.silby.com> References: <84537.1107153288@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Mon, 31 Jan 2005 12:46:43 +0000 cc: Robert Watson cc: current@FreeBSD.org cc: Colin Percival Subject: Re: tcp_isn_tick() / dummynet() callout madness ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2005 07:16:15 -0000 On Mon, 31 Jan 2005, Poul-Henning Kamp wrote: > In message <20050130191410.R62670@odysseus.silby.com>, Mike Silbersack writes: > > One of the things I would like to see is for the callout api to gain > a mutex pointer. > > If the pointer is not null, a mtx_trylock() is atempted, if it fails > a taskq is used to execute this callout, otherwise the function is used > as usual. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 That sounds neat, but I'm not sure it's a good idea. In the case of tcp timers, there are multiple locks that are relevant, if I'm not mistaken. I also have this feeling that when mutex contention really matters, under serious load, it wouldn't be a good idea to indefinitely delay some callouts. I'd propose a simpler approach: Two callout wheels. A "fast" callout wheel for short callouts (like tcp_isn_tick), and a "slow" callout wheel, for things like tcp timers which we should handle quickly, but won't care too much if they get delayed. Scott, in your reply to this you mention the importance of callouts firing on time - do we have such important callouts? Thinking from a system resource perspective, are there callouts that free memory, garbage collect, etc? It would make sense to give those priority over less critical timers which might block. Mike "Silby" Silbersack