On 09/10/2007, Matthew Dillon <[EMAIL PROTECTED]> wrote: > :"...further development like full tickless systems, where the time > :slice is controlled by the scheduler, variable frequency profiling, > :and a complete removal of jiffies in the future." > : > :AFAIK this kind of thing is orthogonal to the goals of this project, > :but it still seems an interesting idea -- one which might eventually > :be of interest here. Dunno. > : > :Any opinions on this tickless idea, pros/cons/relevance? > > Well, DragonFly already uses its systimer API for nearly all timer > events in the system. There is still a base tick but, for example, > the scheduler has its own periodic event. The base tick in DragonFly > drives process statistics, the 'ticks' counter, and the seconds counter, > and that's pretty much it. > > The real issue here is probably cutting down on timer events when a > system is idle - almost certainly to improve the efficiency of > virtualized systems. I think it's a separate problem space. It would > certainly be possible for our various subsystems to detect an idle > condition and stop requesting periodic timeouts in that situations. > I'm not sure its worth doing, though.
It might be useful for power consumption purposes, too. For example, on my Core 2 Duo Allendale box, default FreeBSD 7.0-CURRENT consumes about 2W more power in the idle loop than DragonFly BSD or OpenBSD due to the increased number of clock interrupts that it processes. http://lists.freebsd.org/pipermail/freebsd-arch/2007-September/006807.html Whereas going from 1000HZ to 100HZ saves me 2W, I'm not going to guess how much savings one would get from going lower than 100HZ -- maybe there won't be any significant savings in that direction. C.