Tickless system?
I noticed that the linux kernel config menu introduced an item a few months ago called 'tickless system': This option enables a tickless system: timer interrupts will only trigger on an as-needed basis both when the system is busy and when the system is idle. ...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?
Re: Tickless system?
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.
Re: Tickless system?
Constantine A. Murenin wrote: On 09/10/2007, Matthew Dillon [EMAIL PROTECTED] wrote: ... 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... 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... Interesting point, thanks. How do you measure power consumption?
Re: Tickless system?
On 09/10/2007, walt [EMAIL PROTECTED] wrote: Constantine A. Murenin wrote: On 09/10/2007, Matthew Dillon [EMAIL PROTECTED] wrote: ... 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... 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... Interesting point, thanks. How do you measure power consumption? I use a device called Kill A Watt: http://www.newegg.com/Product/Product.aspx?Item=N82E16882715001 C.
