my geode tsc has a bug - it stops, or slows, when the scheduler decides
to go idle.
The GenericTimeSystem patches test the tsc, detect the slip, and derate
the clocksource,
and booting with idle=poll makes the tsc pass that test.
It occurred to me that updating a seqlock before idling might be nearly
free,
and updating another when waking might be too.
How far wrong is this silly assertion ?
In principle, knowing that the tsc is usable for some timestamp is good.
I doubt that the costs of checking the lock make it worth contemplating,
esp as there are 2 workarounds, but it sounds maybe tinker-worthy:
? how often does the scheduler go 'idle'
? how to capture the slip statistically
apologies for musing out loud
-jimc
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
