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