Tickless system?
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.
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.
More information about the Users
mailing list