From owner-freebsd-current@FreeBSD.ORG Mon Jan 31 06:49:48 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 5AEBD16A4CE; Mon, 31 Jan 2005 06:49:48 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B89743D1D; Mon, 31 Jan 2005 06:49:45 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.19] (ibook-nai.samsco.home [192.168.254.19]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id j0V6rD4i031257; Sun, 30 Jan 2005 23:53:13 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <41FDD507.2040409@samsco.org> Date: Sun, 30 Jan 2005 23:49:43 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Poul-Henning Kamp References: <84537.1107153288@critter.freebsd.dk> In-Reply-To: <84537.1107153288@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: Mike Silbersack 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 06:49:48 -0000 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. > Taskqueues really are very non-deterministic and a poor choice for periodic events. They really are only suitable for events that are uncommon and don't require any sense whatsoever of urgency. While the callout API doesn't have any real-time guarantees, there is an assumption that assigned callouts will be generated with a reasonable amount of accuracy and consistency, and not be held up by a task that has an indefinite run time. Either a new dedicated kthread-based task needs to be created for what you propose, or the simplier approach can be taken of just deferring callouts that fail the trylock test to the end of the list. Scott