Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 14 Jan 2003 03:10:20 -0800 (PST)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        Igor Sysoev <is@rambler-co.ru>
Cc:        arch@FreeBSD.ORG
Subject:   Re: getsysfd() patch #1 (Re: Virtual memory question)
Message-ID:  <200301141110.h0EBAKT0079775@apollo.backplane.com>
References:   <Pine.BSF.4.21.0301141233180.26727-100000@is>

next in thread | previous in thread | raw e-mail | index | archive | help
: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 
					<dillon@backplane.com>

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200301141110.h0EBAKT0079775>