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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
