Date: Mon, 22 Sep 1997 19:26:39 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: gibbs@plutotech.com (Justin T. Gibbs) Cc: tlambert@primenet.com, gibbs@plutotech.com, nate@mt.sri.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: <199709221926.MAA16814@usr06.primenet.com> In-Reply-To: <199709221559.JAA17865@pluto.plutotech.com> from "Justin T. Gibbs" at Sep 22, 97 09:58:54 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >A more deterministic implementation would associate an absolute tick > >value (rather than a count) with each entry, and insert entries in > >sorted order. > > More deterministic for who? This trades O(1) insertion for O(hash chain > length) insertion so that softclock will become O(timeouts for the current > tick). As timeout often is called from an interrupt context > it is not so clear where it is better to pay the price of non-determinism. I'm not so sure timeouts should be called from an interrupt context, ever. If they should, then they should really only be called for the fastintr code. Other interrupts should create a context record that identifies the processing information and queue it as if it were a "request for service" instead of treating it as a "demand for service". This architecture, since it requires the service function to restart acceptance of interrupts on the serviced device, also nicely provides a mechanism for forwarding interrupts to user space (per the strange request of the other day). > Softclock has the luxury of lowering it's spl at deterministic intervals > (see the implementation) while a caller from an interrupt context doesn't. > the current implementation always blocks interrupts for a deterministic > amount of time. What you propose doesn't. O(hash chain length) insertion and O(1) event identification beats O(1) insertion and O(total number of timeouts) event identification, which is what you get from an unordered list. You are assuming here that the softclock resoloution is higher frequency by at least one harmonic range than the interval for any event you wish to schedule. I submit that this is an invalid assumption. On a 586 or better (the only things with a high enough CPU clock frequency to make this worrisome), you can read the inctruction cycle counter, and use it to subtract out firing time. For non-586 hardware, you can multiply by 10 the frequency, and get a statisticaly close approximation using a drift-count (the current code uses a drift count for the time reported as the system clock anyway). > Even so, it is probably better to store an absolute tick value regardless > so that you don't have to perform the subtraction. Yes, at a minimum. Also, if the list is sorted, you do not have to traverse it in it's entirety. > If and when we decide that we need higher resolution timer facilities, we can > decide if a non-deterministic timeout() is an acceptable cost for that > feature. I think they are needed to replace all occurances of delay loops in the kernel. At the very least, this would mean that I could concurrently probe other hardware while probing IDE or "waiting for scsi devices to settle". 8-(. They are also a necessary component for an involuntary context switch of a non-RT process in favor of an RT process for hard RT services. Regards, 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?199709221926.MAA16814>