Constantine A. Murenin
mureninc at gmail.com
Tue Oct 9 17:32:50 PDT 2007
On 09/10/2007, Matthew Dillon <dillon at apollo.backplane.com> 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.
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.
More information about the Users