Date: Thu, 6 Apr 1995 07:56:12 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, terry@cs.weber.edu Cc: freebsd-hackers@FreeBSD.org, paul@isl.cf.ac.uk, rgrimes@gndrsh.aac.dev.com, steve2@freefall.cdrom.com Subject: Re: Colorado Jumbo 250MB ft, and FreeBSD 2.0R Message-ID: <199504052156.HAA31671@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> >That DELAY is hardware dependent is an inevitable side effect of >> >the fact that it is not implemented using real timer code. >> >> It is implemented using real timer code. Read the code before >> commenting. >Oh, well, then the symptoms being reported aren't happening. 8-). >I didn't realize real timer code had been implemented where a >kernel thread switch occurrs and a timer event is scheduled instead >of blocking the kernel thread that called DELAY until the time period >has expired. It's implemented using a real timer (an 8254). It just spins on the timer. It isn't real time code :-). Actually it would be if interrupts were always disabled - then a minimal machine-delay could be guaranteed. The Linux delay routine spins on a loop that was calibrated at boot time. Since there are caches and interrupts around, it isn't possible to guarantee accuracy. It's easier to guarantee that spinning on the timer takes >= the specified time. Some drivers would break if DELAY() could be preempted. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504052156.HAA31671>