From owner-freebsd-arch@FreeBSD.ORG Thu Nov 30 09:42:50 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2059116A407; Thu, 30 Nov 2006 09:42:50 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5405943CA5; Thu, 30 Nov 2006 09:42:42 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: waeY3scLM7Rs5zHA9X5AxA== X-Cloudmark-Score: 0.000000 [] Received: from [193.217.137.195] (account mc467741@c2i.net HELO [10.0.0.249]) by mailfe06.swip.net (CommuniGate Pro SMTP 5.0.12) with ESMTPA id 342876043; Thu, 30 Nov 2006 10:42:46 +0100 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Thu, 30 Nov 2006 10:42:25 +0100 User-Agent: KMail/1.7 References: <7105.1163451221@critter.freebsd.dk> In-Reply-To: <7105.1163451221@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611301042.27175.hselasky@c2i.net> Cc: arch@freebsd.org, Poul-Henning Kamp 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: Thu, 30 Nov 2006 09:42:50 -0000 On Monday 13 November 2006 21:53, 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 > ---------------- > > tick_t XXX_ns_tick(unsigned nsec, unsigned *low, unsigned *high); > Caculate the tick value for a given timeout. > Optionally return theoretical lower and upper limits to > actual value, > > tick_t XXX_s_tick(unsigned seconds) > Caculate the tick value for a given timeout. > > The point behind these two functions is that we do not want to > incur a scaling operating at every arming of a callout. Very > few callouts use varying timeouts (and for those, no avoidance > is possible), but for the rest, precalculating the correct > (opaque) number is a good optimization. > Hi, I have some comments on the matter. Is XXX_arm only an init routine? If not, it does not make sense that one is allowed to pass a variable mutex argument. This will lead to some locking problems I think. Also I am missing the CALLOUT_RETURNUNLOCKED flag. > XXX_arm(struct xxx*, tick_t, func *, arg *, int flag, struct mtx *); > Arm timer. > Struct xxx must be zeroed before first call. > > If mtx pointer is non-NULL, acq mutex before calling. This makes sense. Should also require this for rearm/disarm, but not drain. > > flags: > XXX_REPEAT > XXX_UNLIKELY > > Arm a callout with a number of optional behaviours specified. > > XXX_rearm(struct xxx*, tick_t) > Rearm timer. > > XXX_disarm(struct xxx*) > Unarm the timer. > > XXX_drain(struct xxx*) > Drain the timer. > > > The functions above will actually be wrappers for a more generic > set of the same family, which also takes a pointer to a callout-group. > > This is so that we can have different groups of callouts, for > instance one group for the/each netstack and one for the disk-I/O > stuff etc. Why can't you just rename and extend the existing callout_init_mtx()/callout_reset()/callout_stop()/callout_drain() functions ? Yours --HPS