Date: Tue, 14 Jan 2003 03:31:41 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Igor Sysoev <is@rambler-co.ru>, arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) Message-ID: <3E23F51D.4AD21462@mindspring.com> References: <Pine.BSF.4.21.0301141233180.26727-100000@is> <200301141110.h0EBAKT0079775@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon wrote: > 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. Actually, the callout queue is a significant amount of overhead, when you mode to a large number of TCP/IP connections (e.g. 50,000; you don't even need to go to the 1.6 million I pushed it to, at one point). The problem is that, even with a very large callout wheel, the number of elements in each bucket's list becomes prohibitively large. If you start adding a bunch of other elements into buckets, then you exacerbate the problem. The argument against it on the basis of timers that get deleted before they fire is bogus though (see previous argument). > 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. This is a bogus argument, too: why implement them, if you do not expect them to be used? The idea of timer descriptors is somewhat bogus; you aren't going to do read's or writes on them, so getitimer is just as good as open, for getting a handle to refer to the things. 8-). > The kqueue timer is rather ad-hoc. It's not nearly sophisticated > enough. Yes. The single timer timeout facility, ala select(2), sucks... ala select(2). It was never really intended to be a heavy-duty implementation, though you can use it to build one, as long as you don't care about strict intervals. Linux is better about this, with their bogofied select(2) that does what the man page has been threatening it might do, for a long time, which is to adjust the remainder in the timer. In any case, you are still skewed by the processing interval of whatever intermediate task you happen to do as a result of an event that cause the select/kqueue to come true instead of the timer firing. So real interval timers are useful. I'm just not sure *how* useful, past getitimer/setitimer. > 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) On FreeBSD, this will never be better than "some time after the minimum interval has expired", because FreeBSD is not a hard RT system. Some people argue that you can't implement a hard RT system on PC hardware, but the people who argue that are mostly idiots (i.e. my granularity requirements might be 1 second, which is easy to achieve on a 2.8 GHz CPU, don't you think?). > * one-shot, periodic Natch. Supporting that's one of the problems with itimers. > * 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. Don't know how atomically this can be done... > * Software interrupt (could be thought of as an upcall I suppose) > on completion, or signal, or some other completion mechanism > (kqueue). Signals are stupid, but setitimer supports them. Kqueue support for pretty much anything is trivial. But it doesn't need to be an fd for that, only a handle on which kevent's can be registered, so long as the handle is unique in the registration domain (e.g. my patches that added support for System V message queues). > When I'm talking about timers, I mean the real deal. Not the pipsqueak > little timers implemented by kqueue. You mean implemented as the timeout parameter in kqueue; there's no reason that the kqueue can't be used as the event communication mechanism for itimers (for example). I believe that supporting one-shots would be within the realm of the standard, in terms of implementation defined flags on itimers... -- Terry 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?3E23F51D.4AD21462>