Date: Mon, 22 Sep 1997 21:02:27 +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: <199709222102.OAA23943@usr06.primenet.com> In-Reply-To: <199709222029.OAA00790@pluto.plutotech.com> from "Justin T. Gibbs" at Sep 22, 97 02:29:13 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >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(). This depends on whether I want timeouts to be "hard". If I want them to be hard, than this is unacceptable: a hard timeout needs to occur in expiration order. To get that with an unsorted list is O(n^2). > >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. HRT services or LRT services are irrelevent; I haven't made a strict frequency requirement so far (though I did note that I could see use for HRT). The question is how "hard" the timeout is when it does occur. See my other posting on how to reduce the insertion time further. I agree that insertion time is a factor based on frequency of insertion relative to timer scheduling frequency (it actually get worse, the higher the timer resoloution). So I agree with you that insertion and deletion are "more important" in that case. However. For a timer that is not going to expire, and has been scheduled for some 'n' ticks in the future, and will be removed some 'm' ticks in the future without firing, I can take up to 'n-m' ticks, at the absolute outside, to schedule the thing. Further, if I do not schedule deltas, then the time it takes to get it on the list is absolutely irrelevant. I am saying "timer, fire at this tick". So long as it's on the list before "this tick", I'm fine. Going back to the non-expiration case, so long as the number of ticks from the firing tick calculation time to the time it is removed as "never going to fire" is more the the time it takes to insert, act, and remove, I'm fine. Generally, all this means is that you make the potentially "lost" call that is timing out before you enqueue the timer. > 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. Agreed. However, there is no definite requirement on such architectures that the clock fire; you could just as easily delay-poll (which you will have to do anyway) to implement timing. > 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. I'm not. The only HRT issue is the resoloution of the delay between when a timeout is scheduled to fire and when it actually runs. > 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. Nope, sorry. I read CVS logs for files that impact me, and generally let whoever do whatever behind my back so long as it doesn't affect me. 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?199709222102.OAA23943>