Re: Resistance to documentation? (was Re: Pull in upstream before 9.1 code freeze?)
> 1) XML output from some sysctl variables. It isn't just stupid. It's sad. > 2) bsdlabel -e allows editing only when NONE of partitions are open/mounted, in spite that they are not modified. In FreeBSD 6 it allowed editing everytime and all worked. > > "Preventing people doing stupid things would prevent doing clever things". ^ Bsdlabel was a monstrosity that required a calculator to hand to do anything useful. Gpart on the other hand is easily scriptable. off topic. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Resistance to documentation? (was Re: Pull in upstream before 9.1 code freeze?)
to me...man pages are -reference- material. They are not intended to be the 'right way' to learn something, but instead as a quick reference guide. manual pages are intended to PROPERLY describe how program/function etc. operates. Of course, I doubt anyone can make a case for the 'one true right way' to learn FreeBSD. True. I would never teach someone to read the man pages as a way to familiarize themselves with...say...geom(8). (In fact, I'd love to find some why? The notion of a 'new user' is unfortunately too wide of a category to target documentation to. The problem of today is "persistent new user". "New user since first time touched computer". A secretary who's never seen anything but windows, a 5 year old child, and a fresh PhD in computer science might all fit this category. Each of these people requires different levels of teaching. Secretary should not be FreeBSD admin, while of course can be FreeBSD user. Unix makes clear distinction between user and admin. Modern computing style blurs it. Everytime I see these discussions my mind flashes to a web based wiki where everyone writes helpful information (like the Emacs Wiki) on various topics and it's fairly well indexed so you can see related ideas. Does something like this exist for FreeBSD? No idea. What i HATE in very modern software is wiki-style "documentation". 4) Adding features that are not really finished and in working state. gjournal is an example, background fsck is another (everyone actually ends in background_fsck=NO) Well you have me there, I thought background fsck worked...I just left it on because it's set like that in /etc/defaults/rc.conf. snapshots do crash on big filesystems. And after background fsck often you will find more errors by foreground fsck. Anyway it is not a problem really. Just don't make bulky virtual volumes of 100 disks, as it is not just slow to fsck but dangerous. if your server works for people that cannot stand half an hour of downtime then change to 0 all /etc/fstab positions except of most important, then after a crash do fsck after worktime. with softupdates it is generally safe to run filesystem without fsck for some time. Of course in the same time where are hundreds of good things done, and we all know it. But if people won't understand a problem NOW and fight it, it will become worse. If everyone is busy fighting evil, who is left to create the good? :) First "good" must be needed. Now "good" is defined by democratic means buy herd of "persistent newbies". Doing nothing is actually better than create new "goods" like that. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Is there a reason that xhci isn't mentioned in NOTES in 8-stable?
The xhci code in 8-stable works, but it's not mentioned in the NOTES files in sys/conf, sys/i386/conf, or sys/amd64/conf. The module is hooked up in sys/modules/usb/Makefile, and that's how I've been using it so far. Is it not possible to compile this code into the kernel? Doug -- Change is hard. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Is there a reason that xhci isn't mentioned in NOTES in 8-stable?
On Thursday 19 July 2012 11:14:42 Doug Barton wrote: > The xhci code in 8-stable works, but it's not mentioned in the NOTES > files in sys/conf, sys/i386/conf, or sys/amd64/conf. The module is > hooked up in sys/modules/usb/Makefile, and that's how I've been using it > so far. Is it not possible to compile this code into the kernel? > > Doug Yes, you can compile xhci into the kernel using "device xhci". Not sure who's responsible for updating NOTES. --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Is there a reason that xhci isn't mentioned in NOTES in 8-stable?
On 07/19/2012 02:17, Hans Petter Selasky wrote:
> On Thursday 19 July 2012 11:14:42 Doug Barton wrote:
>> The xhci code in 8-stable works, but it's not mentioned in the NOTES
>> files in sys/conf, sys/i386/conf, or sys/amd64/conf. The module is
>> hooked up in sys/modules/usb/Makefile, and that's how I've been using it
>> so far. Is it not possible to compile this code into the kernel?
>>
>> Doug
>
> Yes, you can compile xhci into the kernel using "device xhci". Not sure who's
> responsible for updating NOTES.
That would be you. :) (Since AFAICS you added the code.) It should
almost certainly also be in the GENERIC files for the systems to which
it applies.
In HEAD and stable/9 it's in sys/conf/NOTES, and
{amd64|i386}/conf/GENERIC; so the same should probably go for stable/8.
Not sure if the code works on stable/7 or not, but we're going to do
another release in stable/8 so it should be updated there for sure.
Doug
--
Change is hard.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Is there a reason that xhci isn't mentioned in NOTES in 8-stable?
On Thursday 19 July 2012 11:38:11 Doug Barton wrote:
> On 07/19/2012 02:17, Hans Petter Selasky wrote:
> > On Thursday 19 July 2012 11:14:42 Doug Barton wrote:
> >> The xhci code in 8-stable works, but it's not mentioned in the NOTES
> >> files in sys/conf, sys/i386/conf, or sys/amd64/conf. The module is
> >> hooked up in sys/modules/usb/Makefile, and that's how I've been using it
> >> so far. Is it not possible to compile this code into the kernel?
> >>
> >> Doug
> >
> > Yes, you can compile xhci into the kernel using "device xhci". Not sure
> > who's responsible for updating NOTES.
>
> That would be you. :) (Since AFAICS you added the code.) It should
> almost certainly also be in the GENERIC files for the systems to which
> it applies.
>
> In HEAD and stable/9 it's in sys/conf/NOTES, and
> {amd64|i386}/conf/GENERIC; so the same should probably go for stable/8.
> Not sure if the code works on stable/7 or not, but we're going to do
> another release in stable/8 so it should be updated there for sure.
I've MFC'ed the NOTES bit, but I'm not sure about the GENERIC bit.
http://svn.freebsd.org/changeset/base/238616
--HPS
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Is there a reason that xhci isn't mentioned in NOTES in 8-stable?
On 07/19/2012 03:29, Hans Petter Selasky wrote:
> On Thursday 19 July 2012 11:38:11 Doug Barton wrote:
>> On 07/19/2012 02:17, Hans Petter Selasky wrote:
>>> On Thursday 19 July 2012 11:14:42 Doug Barton wrote:
The xhci code in 8-stable works, but it's not mentioned in the NOTES
files in sys/conf, sys/i386/conf, or sys/amd64/conf. The module is
hooked up in sys/modules/usb/Makefile, and that's how I've been using it
so far. Is it not possible to compile this code into the kernel?
Doug
>>>
>>> Yes, you can compile xhci into the kernel using "device xhci". Not sure
>>> who's responsible for updating NOTES.
>>
>> That would be you. :) (Since AFAICS you added the code.) It should
>> almost certainly also be in the GENERIC files for the systems to which
>> it applies.
>>
>> In HEAD and stable/9 it's in sys/conf/NOTES, and
>> {amd64|i386}/conf/GENERIC; so the same should probably go for stable/8.
>> Not sure if the code works on stable/7 or not, but we're going to do
>> another release in stable/8 so it should be updated there for sure.
>
> I've MFC'ed the NOTES bit, but I'm not sure about the GENERIC bit.
>
> http://svn.freebsd.org/changeset/base/238616
Thanks! What are your concerns about adding it to GENERIC?
--
Change is hard.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Is there a reason that xhci isn't mentioned in NOTES in 8-stable?
On Thursday 19 July 2012 12:34:34 Doug Barton wrote:
> On 07/19/2012 03:29, Hans Petter Selasky wrote:
> > On Thursday 19 July 2012 11:38:11 Doug Barton wrote:
> >> On 07/19/2012 02:17, Hans Petter Selasky wrote:
> >>> On Thursday 19 July 2012 11:14:42 Doug Barton wrote:
> The xhci code in 8-stable works, but it's not mentioned in the NOTES
> files in sys/conf, sys/i386/conf, or sys/amd64/conf. The module is
> hooked up in sys/modules/usb/Makefile, and that's how I've been using
> it so far. Is it not possible to compile this code into the kernel?
>
> Doug
> >>>
> >>> Yes, you can compile xhci into the kernel using "device xhci". Not sure
> >>> who's responsible for updating NOTES.
> >>
> >> That would be you. :) (Since AFAICS you added the code.) It should
> >> almost certainly also be in the GENERIC files for the systems to which
> >> it applies.
> >>
> >> In HEAD and stable/9 it's in sys/conf/NOTES, and
> >> {amd64|i386}/conf/GENERIC; so the same should probably go for stable/8.
> >> Not sure if the code works on stable/7 or not, but we're going to do
> >> another release in stable/8 so it should be updated there for sure.
> >
> > I've MFC'ed the NOTES bit, but I'm not sure about the GENERIC bit.
> >
> > http://svn.freebsd.org/changeset/base/238616
>
> Thanks! What are your concerns about adding it to GENERIC?
Hi,
I don't see any problems at the present. I think all issues have been ironed
out including the 32/64 byte context sizes. From what I'm aware the XHCI
driver in 8-stable should be the same like in 9- and 10- except from a recent
patch done by mav @. This patch should not make a big difference, except for
INTEL patherpoint devices.
--HPS
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: kqueue periodic timer confusion
On Fri, 2012-07-13 at 07:22 -0500, Davide Italiano wrote:
> On Thu, Jul 12, 2012 at 5:25 PM, John Baldwin wrote:
> > On Thursday, July 12, 2012 11:08:47 am Davide Italiano wrote:
> >> On Thu, Jul 12, 2012 at 4:26 PM, John Baldwin wrote:
> >> > On Thursday, July 12, 2012 9:57:16 am Ian Lepore wrote:
> >> >> 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) + (((100 +
> >> >> > 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 bot
Re: kqueue periodic timer confusion
On Thu, Jul 19, 2012 at 5:06 PM, Paul Albrecht wrote:
> On Fri, 2012-07-13 at 07:22 -0500, Davide Italiano wrote:
>> On Thu, Jul 12, 2012 at 5:25 PM, John Baldwin wrote:
>> > On Thursday, July 12, 2012 11:08:47 am Davide Italiano wrote:
>> >> On Thu, Jul 12, 2012 at 4:26 PM, John Baldwin wrote:
>> >> > On Thursday, July 12, 2012 9:57:16 am Ian Lepore wrote:
>> >> >> 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) + (((100
>> >> >> > > > +
>> >> >> > 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 ti
Awful FreeBSD 9 block IO performance in KVM
Dear Everyone, FreeBSD 9 has awful block IO performance in KVM. I have experienced it and others have experienced it. Someone posted slides to slideshare with benchmarks documenting it: http://www.slideshare.net/TakeshiHasegawa1/runningfreebsdonlinuxkvm Slides 13 and 20 are particular eye openers. Does anyone know what is wrong? Yours truly, Richard Yao signature.asc Description: OpenPGP digital signature
Re: kqueue periodic timer confusion
on 19/07/2012 18:11 Davide Italiano said the following:
> On Thu, Jul 19, 2012 at 5:06 PM, Paul Albrecht wrote:
>> On Fri, 2012-07-13 at 07:22 -0500, Davide Italiano wrote:
>>> On Thu, Jul 12, 2012 at 5:25 PM, John Baldwin wrote:
On Thursday, July 12, 2012 11:08:47 am Davide Italiano wrote:
> On Thu, Jul 12, 2012 at 4:26 PM, John Baldwin wrote:
>> On Thursday, July 12, 2012 9:57:16 am Ian Lepore wrote:
>>> 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) + (((100 +
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
>>>
