Date: Mon, 22 Sep 1997 14:29:13 -0600 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: Terry Lambert <tlambert@primenet.com> Cc: gibbs@plutotech.com (Justin T. Gibbs), 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: <199709222029.OAA00790@pluto.plutotech.com> In-Reply-To: Your message of "Mon, 22 Sep 1997 19:26:39 -0000." <199709221926.MAA16814@usr06.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> 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. Timeouts aren't ever called from a hardware interrupt context, they are called from softclock at splsoftclock. If you re-read what I wrote, I said that timeout() and untimeout() are often called from within interrupt contexts (untimeout more often than timeout) and that for this reason, those two routines should have deterministic running times. >> 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. Sure, assuming that's what you have, but the new scheme is O(hash chain length) event identification in softclock + O(1) insertion/removal. Go read the paper or the code. I maintain that softclock occurs lest often than insert/removal, so paying the price in softclock is better than doing so on insertion. >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. Did I? I assumed that the resolution of softclock was <= to the interval of any event currently scheduled by the kernel. Softclock nominally happens hz times a second, but since it can be delayed by other interrupt processing, it's frequency can be somewhat less than hz. All timeouts are scheduled in terms of hz. Until we decide that higher resolution timers are required, this will continue to be the case. >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. So. >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). So. The current implementation doesn't attempt to offer high resolution timing facilities, so this discussion is not relevant. >> 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. You do during a call to timeout(). >> If and when we decide that we need higher resolution timer facilities, we ca >n >> 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-(. Having high resolution timers has nothing to do with the ability to remove DELAYs from the kernel especially during device configuration. You simply cannot have interrupts enabled during the early stages of device configuration on all architectures. On the x86, yes, you could just not mask the clock interrupt and get this facility early at boot, but I would not suggest relying on it as on other hardware this may be impossible. Of course, if you don't want to wait for your SCSI devices to settle, you can start using the CAM SCSI code. It does this by postponing the probing of SCSI busses until interrupt services are available, probes all buses in parallel, then allows the mounting of root and the rest of the boot to proceed. Amazingly enough, I had this code working before I changed the callout interface and I didn't use a single high resolution timer to make it work either! I'm sure you're shocked. BTW, the code to do "interrupt driven configuration" was committed at the same time as the callout changes, but I guess you didn't read all of my commit message. > Regards, > Terry Lambert > terry@lambert.org >--- >Any opinions in this posting are my own and not those of my present >or previous employers. > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations ===========================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709222029.OAA00790>