[RFC] Event timers on sparc64/sun4v

[Alexander Motin]

John Baldwin wrote:
> On Sunday, July 18, 2010 10:05:08 am Marius Strobl wrote:
>> Apart from that I'm not really happy about that construct
>> myself but I don't see an alternative to always bind to
>> the same CPU when reading the tick counter in order to
>> get reliable results and in US-IIIi-based machines there
>> just isn't another piece of hardware besides the per-CPU
>> stick and tick counters that could be used as a timecounter
>> available.
> 
> You could check td_critnest perhaps in your routine and if it is non-zero just 
> return the cached value of the timecounter from the last time it was polled 
> from tc_ticktock() (effectively turning those instances of getfootime() into 
> just footime()).  Things like gettimeofday() would still be correct as they 
> can safely bind to the BSP, and I doubt many interrupt handlers are actually
> using getfootime().

Thinking about tickless kernel and looking how it is done in Linux I
have feeling that we may need to call getbinuptime or something alike in
the interrupt threads to properly schedule events. At this moment I
don't see another way to avoid time drift due to interrupt latency and
other delays. That's why I would like this issue to be fixed in some
better and less consuming way. May be using per-CPU ticker could help at
that specific question, but I still don't like the situation. In future
it may be not very good to wake up exactly CPU0 from sleep just to
update system time for other cores, as it is done now.

-- 
Alexander Motin