Date: Mon, 22 Sep 1997 06:47:44 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: gibbs@plutotech.com (Justin T. Gibbs) Cc: nate@mt.sri.com, gibbs@plutotech.com, current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/conf files src/sys/dev/vx if_vx.c if_vxreg.h src/sys/i386/apm apm.c src/sys/i386/conf GENERIC files.i386 Message-ID: <199709220647.XAA16869@usr07.primenet.com> In-Reply-To: <199709220548.XAA08824@pluto.plutotech.com> from "Justin T. Gibbs" at Sep 21, 97 11:48:42 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >Does anyone have insight they're willing to share, since the author's > >did prove they accomplished what they set out to do, but it didn't > >really give me a warm-fuzzy that it would help improve performance. > > Take a server with 10 Seagate disks. Each one of these disks can > handle 63 transactions at a time. If you split the disks across > controllers correctly, you can readily keep them saturated with > requests. Thats 630 pending callouts and an O(n) hit for insert > and removal. Add to that any process alarm timers, the network stack's > timer, the serial ports timeout or two, etc. It really adds up and > it defenitly shows up in profiles. A more deterministic implementation would associate an absolute tick value (rather than a count) with each entry, and insert entries in sorted order. The tick value would be monotonically increasing, and a comparison need only occur with the list head (the smallest absolute value). When the timer fires, the entry is removed, and following the callout, subsequent entries are examined until such time that the absolute tick count is smaller than the list head entry's absolute tick count. This wins because it means your traversal time in the normal case is not variant based on the length of the list. Because of this, you can maintain an accurate soft clock based on how many cycles you know the timer code itself will take (it's deterministic, at this point). Finally, you don't need to maintain a constant timer frequency. The expiration of the head is all that matters, so you can set the timer to expire at some absolute time that matches the head entry... you don't need to kick the frequency up to match the interval resoloution for the highest resoloution entry, as you would for a ntry-tick-decrement based implementation. Finally, if you allowed a timer outcall to reschedule itslef, you could remove the HZ clock to a timer entry as well. Someone should look at the Linux 2.1 kernel; they have implemented the reschedulable one-shots that I first discussed in 1993, and can now probe devices concurrently instead of using delay buzz-loops (also as I first discussed in 1993). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709220647.XAA16869>