Thanks Finn,
Am 09.11.2018 um 12:42 schrieb Finn Thain:
On Sun, 28 Oct 2018, Geert Uytterhoeven wrote:
The example I gave was GENERIC_CLOCKEVENTS on m68, which is
supported on most but not all machines there.
That suggests that the removal of just those machines would suffice
(as opposed to the removal of the entire arch).
Also, Documentation/features/time/clockevents/arch-support.txt says,
| m68k: | ok |
These two observations make me wonder whether the clockevents feature
is related to the discussion quoted above (?)
GENERIC_CLOCKEVENTS is selected only for a few Coldfire CPU types.
!GENERIC_CLOCKEVENTS implies PREEMPT_NONE, and disables the "Timers
subsystem" (i.e. the NO_HZ config options), but it works fine -- I was
able to convert the Mac port to !ARCH_USES_GETTIMEOFFSET &&
!GENERIC_CLOCKEVENTS. (Like many of the Coldfire CPU types.)
You can see those patches here,
https://github.com/fthain/linux/commits/mac68k-queue/
Note that !ARCH_USES_GETTIMEOFFSET is a build-time choice, meaning that
all platforms need to be converted together.
Also, some platforms will need to adopt the clocksource API, otherwise the
built-in "jiffies" clocksource will get used, causing a regression in
timer accuracy.
Conversion to the clocksource API is straight-forward where the platform
already implements arch_gettimeoffset. The conversion is discussed in
include/linux/time.h:
/* Some architectures do not supply their own clocksource.
* This is mainly the case in architectures that get their
* inter-tick times by reading the counter on their interval
* timer. Since these timers wrap every tick, they're not really
* useful as clocksources. Wrapping them to act like one is possible
* but not very efficient. So we provide a callout these arches
* can implement for use with the jiffies clocksource to provide
* finer then tick granular time.
*/
(Not sure what is meant by "not very efficient" here.)
Certain 680x0 platforms do not implement arch_gettimeoffset: apollo, q40,
sun3, sun3x. These platforms can fall back on the "jiffies" clocksource
with no loss of timer accuracy, so conversion for these platforms is
trivial.
Should I continue with the clocksource API conversion for the other
platforms: amiga, atari, bvme6000, hp300, mvme147, mvme16x? This would
allow for removal of "select ARCH_USES_GETTIMEOFFSET" (and satisfy
Documentation/features/time/modern-timekeeping) without loss of timer
accuracy.
Alternatively, we could defer the clocksource API conversion, leaving it
up to the platform maintainers (who can actually test the driver changes).
But that would mean that many platforms would suffer a regression in timer
accuracy upon removal of arch_gettimeoffset.
That's ultimately for Geert to decide - I'll yet have to look at your
mac patches to even get a vague idea what this conversion involves, but
I can certainly test whatever you came up with for Mac on Atari.
Tick granularity is 40 us at best on Atari with the current timer
configuration, and can't be increased without increasing HZ. I suspect
the limitations on Mac are similar?
Cheers,
Michael
