Re: [PATCH] s390 (9/9): no timer interrupts in idle.

From: George Anzinger
Date: Thu Apr 22 2004 - 22:34:19 EST

Martin Schwidefsky wrote:

xtime is easy, that's interpolated anyway afaics. Jiffies would either


jump some, which code needs to deal with anyway given that preempt can do
the same, or would become an approximated thing as well based on the


time keeping sources in the system.

Unluckily no. xtime is not easy because the network stack uses this for
time stamps at several locations. Living in the past and time stamps for
network packets don't go together, do they?

calculating the load can be a real timer for sure (which would cause an irq
at that time), cpu limits we can do at the end of timeslice (and set the
timeslice such that the limits won't be exceeded).

Here is where this thing falls down. Some time ago I put together a tick less system (which is what this amounts to). The patch is still on sourceforge (see the HRT URL in my signature). The problem is this:

On context switch the scheduler needs to figure the minimum time to the next event for the new task. This would be the minimum of the remaining slice, profile timer, virtual time, and the cpu limit timer (at least). It would then do an add_timer for this time. On the next context switch it would, most likely, cancel the timer (most code does not run to the end of its slice which is the most likely limit). The computation to find the minimum time, with a bit of hand waving, could be shortened to eliminate a few of the timers. On switch out, all the tasks timers would need to be updated with the actual time the task used. The problem is that all this work is in the VERY lean and mean context switch path. In my tests a context switching could easily occur often enough that the savings from not doing the tick interrupts was over whelmed by the added context switch over head with a medium cpu load. And it is down hill from here. I.e. the tick less system incurres accounting overhead in direct proportion to the number of context switches, while the ticking system has a fixed accounting overhead. AND the cross over point (where the tick less system overhead is more that the ticked system overhead) occurs with a medium load.

George Anzinger george@xxxxxxxxxx
Preemption patch:

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at