Messages in this thread | | | Date | Mon, 3 Apr 2006 21:54:03 +0200 (CEST) | From | Roman Zippel <> | Subject | [PATCH 0/5] clocksource patches |
| |
Hi,
It unfortunately took a bit longer when I planned, but here is now an update to the clocksource patches. Patch 1 depends on the generic clocksource patches. Patches 2-4 are a replacement for these patches in -mm:
time-use-clocksource-infrastructure-for-update_wall_time.patch time-use-clocksource-infrastructure-for-update_wall_time-mark-few-functions-as-__init.patch time-let-user-request-precision-from-current_tick_length.patch time-use-clocksource-abstraction-for-ntp-adjustments.patch time-introduce-arch-generic-time-accessors.patch
Patch 5 depends on the clocksource drivers.
Some more notes about the patches:
1. generic clocksource updates: The most important change is probably clocksource_get_nsec_offset(), it returns the nsec part of the realtime clock and is adjusted once a second. Other time services can be built on top of this and also only have to be updated once a second via second_overflow(). I changed the return value to an unsigned long which gives us a 3 second window, which should be more than enough (anyone not allowing the timer interrupt for that long gets what he is asking for). This function should become clocksource specific so arch/clocks can optimize this function themselves (e.g. changing resolution, making some parameters constant). The generic clocksource currently still deals a bit too much with cycles, more of this should be moved into the clocksource drivers (using library functions).
I'm also still interested in opinions about different possibilities to organize the clocksource infrastructure (although I'd more appreciate pro/con arguments than outright rejections). One possibility here would be to also shorten the function names a bit (clocksource_ is a lot to type :) ), cs_... or clock_... would IMO work too.
2. periodic clocksource update I updated the error adjustment algorithm to be more robust and optimized it a bit for the more common cases. It does everything in 64bit right now, which is fine for 64bit archs and it allows resolutions of less then 1nsec, but as long as e.g. gettimeofday() takes longer than 1nsec that's a little wasteful and nobody will see a difference if we "restrict" the resolution to 1nsec, which would allow to keep parts of it in 32bit.
I also kept it separate from the do_timer() callback and simply created a new callback function, which archs can use. This makes it less likely to break any existing setup and even allows to coexists both methods until archs have been completely converted.
The userspace version I used to test this can be found at http://www.xs4all.nl/~zippel/ntp/clocktest.c
Another general comment from an arch/driver specific perspective: right now everything is rather concentrated on getting the time, but AFAICT it's more common that the subsystem which is used to read the time is also used as timer (i.e. for the scheduler tick), this means the clocksource driver should also include the interrupt setup. Consequently this means the update callback isn't sufficient anymore and we need at least something like start/stop callbacks. This also means the jiffie clocksource becomes basically obsolete, since every arch already needs at least a basic clocksource to provide the scheduler tick (which is setup via time_init()). i386 is currently rather hardcoded to use the i8253 timer, but AFAIK it would be desirable to e.g. use HPET for that (especially for hrtimer). Something like TSC should internally use another clocksource to provide the timer interrupt. Anyway, i386 is quite a mess here right now and I can understand that you wanted to stay away from it with the generic gettimeofday infrastructure. :-) This is not important right now, but I wanted to mention it, it's IMO something to keep in mind for the next steps and what at least I'll look out for.
bye, Roman - 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/
| |