OSDev.org

I'm now reconfiguring the linux kernel for compiling (last version was linux-2.6.20.6), and found the option "Tickless system".

The idea is lowering the IRQ rate by programming the timer only when we need it (I suppose for example if all the processes are sleeping waiting for IO, we don't even need the timer interrupting the idle process every 1/n seconds, we only need to wait for the mouse/kbd/hd/etc IRQ).

Sound very interesting. A question then came to my mind: are there any more OSs supporting this?

JJ

This option only makes sense if you are using the APIC or the HPET timers.
If your using the PIT the I/O port accesses will be way to slow and you will waste a lot of time while adjusting the timer. I'm planning to implement this option when I implement APIC timers.

Korona wrote:This option only makes sense if you are using the APIC or the HPET timers.
If your using the PIT the I/O port accesses will be way to slow and you will waste a lot of time while adjusting the timer.

I haven't played much with the PIT, but I thought you had to reprogram it every time it ticks, even if you always need the same delay.
It's probably because I've been programming a timer with this behavior in computer architecture classes (in my university we use a special processor they invented, P3, which are the initials for "Little Pedagogic Processor", in Portuguese).

JJ

JJeronimo wrote: I haven't played much with the PIT, but I thought you had to reprogram it every time it ticks, even if you always need the same delay.

AFAIK mode 3 allows you to program it once and it will indefinitely continue ticking at the same rate.

Yes, it has a periodic interrupt mode.
Reprogramming it on every tick is bad because inb() and outb() calls are _very_ slow on the x86.

My kernel runs tickless when using the APIC timer and no threads are runnable. It simply doesn't prepare the next tick (I have the timer in one-shot mode) when the idle thread gets scheduled.

If you count the OUTs, tickless systems are better whenever you get more than 4 interrupts without scheduling the process (4xEOI vs 1xEOI + 1x3 bytes to PIT). There's an older discussion on this you can try finding with a search.

Hi,

Combuster wrote:If you count the OUTs, tickless systems are better whenever you get more than 4 interrupts without scheduling the process (4xEOI vs 1xEOI + 1x3 bytes to PIT). There's an older discussion on this you can try finding with a search.

It's not quite that simple...

First, I put the PIT into "hibyte only" mode and leave channel 0 selected, so that a new PIT count can be set with a single I/O port write, and so you get a range from 214.5 us to 54.9 ms (in 214.5 us increments).

Secondly, if the task doesn't use it's entire time slice then the count will be reprogrammed before any IRQ occurs - no EOI necessary.

However, if a task uses a small fraction of it's time slice you'll be doing I/O port writes more often. For e.g. if the PIT is set to 100 Hz and each task runs for 1 ms and blocks, then you get one I/O port access for 10 task switches, but if the PIT is being used in "one-shot" mode you'd get 10 times as many I/O port accesses.

Lastly, if the PIT is being used in "one-shot" mode then you need to keep track of real time somehow. You could read the PIT's remaining count when a task doesn't use it's entire time slice (more I/O port accesses but very precise) or use the CMOS/RTC's periodic IRQ or update IRQ (lots more I/O port accesses), or read the time from the CMOS/RTC's "hour/minute/second" fields (a potentially huge number of I/O port accesses and a complete lack of precision) or use some other way (e.g. RDTSC, which is very hard to get right but is extremely precise).


Cheers,

Brendan

I disable the PIT before HLT-ing the CPU when no thread is runnable. If there's work to do again I reenable the timer. That works quite well.

What is the advantage of doing that? When no running thread you don't have to save clock cycles.

Hi,

Korona wrote:What is the advantage of doing that? When no running thread you don't have to save clock cycles.

It reduces CPU power consumption (less heat, less chance of thermal throttling, less electricity, longer laptop battery life, less fan noise, less "server room" air-conditioning, less global warming, etc).

Taking the CPU out of the HLT state (and out of any other power saving state) for no reason doesn't really help SMP performance either. For e.g. unnecessary bus/memory bandwidth used by one CPU effects the performance of other CPUs trying to use bus/memory bandwidth; and for hyper-threading, unnecessary work done by one logical CPU effects the performance of another logical CPU in the same chip/core.


Cheers,

Brendan