Date: Sat, 6 Apr 1996 09:27:19 -0700 From: Nate Williams <nate@sri.MT.net> To: Tony Kimball <alk@Think.COM> Cc: hackers@freebsd.org Subject: Re: interrupts and such Message-ID: <199604061627.JAA21777@rocky.sri.MT.net> In-Reply-To: <199604060640.AAA03986@compound> References: <199604060640.AAA03986@compound>
next in thread | previous in thread | raw e-mail | index | archive | help
> > This seems excessive ... > > So what is rtc0 and why is it acting like a clock interrupt? > > Because it is a clock interrupt. rtc0 is 'sufficiently' faster than > clk0 so that statistics gathering is significantly better and more > accurate. > > This does not answer the question, however; it merely mutates it: No, I answered both questions. > Why retain clk0? It *does* seem a bit excessive. Both are necessary. It's basically a 'sampling' problem. You must sample faster than events are occuring to more accurately gain information about them. Since the sheduling algorithm still uses clk0 to do it's work (each process gets it's quantum based on clk0) , it's still necessary. However, by using a faster clock to gain information about *what* is running, you get much more accurate statistics. With the current system, it's possible for a process to burn up just a tiny bit less than it's quantum at times but *never* have any of it show up in scheduling or profiling. It could start the quantum in one routine, jump into the 'hog' routine, and return back before the quantum expires. In this case, the scheduler and profiler would not have accurate statistics so therefore couldn't be counted on unless something better existed. (Which we have now). Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604061627.JAA21777>