From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 12 13:57:25 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6195D106566B for ; Thu, 12 Jul 2012 13:57:25 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by mx1.freebsd.org (Postfix) with ESMTP id 4208E8FC0C for ; Thu, 12 Jul 2012 13:57:25 +0000 (UTC) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta03.emeryville.ca.mail.comcast.net with comcast id ZR9L1j0071zF43QA3RxK03; Thu, 12 Jul 2012 13:57:19 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta24.emeryville.ca.mail.comcast.net with comcast id ZRxJ1j00F4NgCEG8kRxKtz; Thu, 12 Jul 2012 13:57:19 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q6CDvG4H015599; Thu, 12 Jul 2012 07:57:16 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: John Baldwin In-Reply-To: <201207120834.40745.jhb@freebsd.org> References: <1342036332.8313.8.camel@albrecht-desktop> <1342040447.1123.31.camel@revolution.hippie.lan> <201207120834.40745.jhb@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Jul 2012 07:57:16 -0600 Message-ID: <1342101436.1123.52.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Paul Albrecht Subject: Re: kqueue periodic timer confusion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 13:57:25 -0000 On Thu, 2012-07-12 at 08:34 -0400, John Baldwin wrote: > On Wednesday, July 11, 2012 5:00:47 pm Ian Lepore wrote: > > On Wed, 2012-07-11 at 14:52 -0500, Paul Albrecht wrote: > > > Hi, > > > > > > Sorry about this repost but I'm confused about the responses I received > > > in my last post so I'm looking for some clarification. > > > > > > Specifically, I though I could use the kqueue timer as essentially a > > > "drop in" replacement for linuxfd_create/read, but was surprised that > > > the accuracy of the kqueue timer is much less than what I need for my > > > application. > > > > > > So my confusion at this point is whether this is consider to be a bug or > > > "feature"? > > > > > > Here's some test code if you want to verify the problem: > > > > > > #include > > > #include > > > #include > > > #include > > > #include > > > #include > > > #include > > > #include > > > > > > int > > > main(void) > > > { > > > int i,msec; > > > int kq,nev; > > > struct kevent inqueue; > > > struct kevent outqueue; > > > struct timeval start,end; > > > > > > if ((kq = kqueue()) == -1) { > > > fprintf(stderr, "kqueue error!? errno = %s", > strerror(errno)); > > > exit(EXIT_FAILURE); > > > } > > > EV_SET(&inqueue, 1, EVFILT_TIMER, EV_ADD | EV_ENABLE, 0, 20, 0); > > > > > > gettimeofday(&start, 0); > > > for (i = 0; i < 50; i++) { > > > if ((nev = kevent(kq, &inqueue, 1, &outqueue, 1, NULL)) == > -1) { > > > fprintf(stderr, "kevent error!? errno = %s", > strerror(errno)); > > > exit(EXIT_FAILURE); > > > } else if (outqueue.flags & EV_ERROR) { > > > fprintf(stderr, "EV_ERROR: %s\n", > strerror(outqueue.data)); > > > exit(EXIT_FAILURE); > > > } > > > } > > > gettimeofday(&end, 0); > > > > > > msec = ((end.tv_sec - start.tv_sec) * 1000) + (((1000000 + > end.tv_usec - start.tv_usec) / 1000) - 1000); > > > > > > printf("msec = %d\n", msec); > > > > > > close(kq); > > > return EXIT_SUCCESS; > > > } > > > > > > > > > > What you are seeing is "just the way FreeBSD currently works." > > > > Sleeping (in most all of its various forms, and I've just looked at the > > kevent code to verify this is true there) is handled by converting the > > amount of time to sleep (usually specified in a timeval or timespec > > struct) to a count of timer ticks, using an internal routine called > > tvtohz() in kern/kern_time.c. That routine rounds up by one tick to > > account for the current tick. Whether that's a good idea or not (it > > probably was once, and probably not anymore) it's how things currently > > work, and could explain the fairly consistant +1ms you're seeing. > > This is all true, but mostly irrelevant for his case. EVFILT_TIMER > installs a periodic callout that executes KNOTE() and then resets itself (via > callout_reset()) each time it runs. This should generally be closer to > regulary spaced intervals than something that does: > In what way is it irrelevant? That is, what did I miss? It appears to me that the next callout is scheduled by calling timertoticks() passing a count of milliseconds, that count is converted to a struct timeval and passed to tvtohz() which is where the +1 adjustment happens. If you ask for 20ms and each tick is 1ms, then you'd get regular spacing of 21ms. There is some time, likely a small number of microseconds, that you've consumed of the current tick, and that's what the +1 in tvtohz() is supposed to account for according to the comments. The tvtohz() routine both rounds up in the usual way (value+tick-1)/tick and then adds one tick on top of that. That seems not quite right to me, except that it is a way to g'tee that you don't return early, and that is the one promise made by sleep routines on any OS; those magical "at least" words always appear in the docs. Actually what I'm missing (that I know of) is how the scheduler works. Maybe the +1 adjustment to account for the fraction of the current tick you've already consumed is the right thing to do, even when that fraction is 1uS or less of a 1mS tick. That would depend on scheduler behavior that I know nothing about. -- Ian