From owner-freebsd-arch Tue Jan 14 3:10:23 2003 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 A3EF237B401 for ; Tue, 14 Jan 2003 03:10:21 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1414743F13 for ; Tue, 14 Jan 2003 03:10:21 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h0EBAK0i079776; Tue, 14 Jan 2003 03:10:20 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0EBAKT0079775; Tue, 14 Jan 2003 03:10:20 -0800 (PST) Date: Tue, 14 Jan 2003 03:10:20 -0800 (PST) From: Matthew Dillon Message-Id: <200301141110.h0EBAKT0079775@apollo.backplane.com> To: Igor Sysoev Cc: arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :kqueue already has EVFILT_TIMER in __FreeBSD_version >= 440001 and :__FreeBSD_version >= 500023. Descriptor-based timers would be non-standard :feature and if you use non-standard features then you should use kqueue :instead of poll or select. : :Nevetheless it seems to me that using many kernel timers is not good :thing if you need frequently to set or delete them (i.e. in web-servers). :It's much better to use user-level timer queue and call :kqueue/poll/select with timeout value from the head of this queue. : : :Igor Sysoev :http://sysoev.ru/en/ There's really nothing wrong with a large number of kernel supported timers. One of my telemetry systems probably has a thousand kernel supported timers operating on a 20MHz 68000. i.e. not an issue if done right. That said, a per-descriptor timer implementation would have no more or less overhead then the kqueue implementation. The software designer isn't being forced to use one descriptor based timer for each soft timer he wants, after all. The kqueue timer is rather ad-hoc. It's not nearly sophisticated enough. The absolute minimum timer and timing support I throw into my embedded systems is: * seconds, 1/10 seconds, realtime_seconds, ticks, fine-grained-ticks (typically the best hardware resolution available). (I'd also add microseconds for a UNIX implementation) * one-shot, periodic * on-the-fly adjust of current count (forwards or backwards), double-buffer (set reload value without effecting current countdown), start, stop reset, reload-absolute, reload-relative. * Software interrupt (could be thought of as an upcall I suppose) on completion, or signal, or some other completion mechanism (kqueue). When I'm talking about timers, I mean the real deal. Not the pipsqueak little timers implemented by kqueue. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message