>We have a Linux kernel (2.4.18-rmk2) running on the IBM Linux Watch which
>skips timer ticks, but only when there's no work to be done. We have dubbed
>this timing scheme the Work Dependent Timing scheme. Briefly, on every
>return to the "Linux idle loop", the kernel checks if there's more work to
>be done by parsing relevant lists and queues. If there's no current work to
>be done, nor any work to be done in the next timer tick, the software timer
>with the nearest timeout is retrieved and a hardware timer is programmed
>accordingly with the nearest timeout to wake up the system in time to service
>the associated software timer.
In principle that is what the version 2 of the s/390 timer patch does. My
timer patch is a bit more complicated since it has to cope with an SMP system
but that are just details in the backend code that deal with the question
which cpu is doing the calls to do_timer(). The idea is to stop the hz timer
for every cpu going idle. The last cpu going idle has to check if something is
on tq_timer. If there is work on tq_timer then the clock is not reprogrammed
and the next hz tick comes in normally. If there is nothing on tq_timer
then the next timer event is calculated from the tv1-tv5 arrays and the
clock comparator is reprogrammed. With that all cpus are truly doing nothing
until either the clock comparator or another hardware interrupt comes in.
That is where the monitor call instruction on s/390 comes into play. This neat
instruction either causes a program check or does nothing (a nop). This is
controlled by a bit in control register 8. So the additional cost on the
system entry path is just one cycle for the nop if a cpu is running normally.
The amount of additional work on the system entry path was the main backdraw
of version 1 of the timer patch.
Version 1 of the s/390 timer patch is even more radical. It eliminates the hz
timer completly. Timer events are done with the clock comparator and process
related timer (time slice, itimer and profiling timer) are done with the cpu
timer. Since there isn't a periodic check anymore every change related to
timers has to be notified to the architecture backend. That makes it necessary
to introduce two hooks timer_notify and itimer_notify that are called from
common code. Not really nice but necessary for this approach. A second, more
severe backdraw is the need to check on every system entry if a jiffy update
needs to be done and to do the calculations for proper process time accounting
(in fact the jiffy variable is replaced by a macro and is not a problem but
the wall_time and other internal timing stuff have to get updated).
This makes up for about 60 cycles in the system entry path. This shows up on
some micro benchmarks and was the reason to do version 2.
blue skies,
Martin
P.S. the two timer patches are available on developer works:
http://www10.software.ibm.com/developerworks/opensource/linux390/current2_4_17.shtml#jun132002-timer
http://www10.software.ibm.com/developerworks/opensource/linux390/current2_4_17-may2002.shtml#timer20020531
Linux/390 Design & Development, IBM Deutschland Entwicklung GmbH
Schönaicherstr. 220, D-71032 Böblingen, Telefon: 49 - (0)7031 - 16-2247
E-Mail: schwidefsky@de.ibm.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jul 23 2002 - 22:00:19 EST