[RFC] Event timers on sparc64/sun4v

[Alexander Motin]

Marius Strobl wrote:
> On Fri, Jul 16, 2010 at 02:18:48PM +0300, Alexander Motin wrote:
>> I've made a patch, updating sparc64/sun4v timer driver to utilize new MI
>> event timer infrastructure. There are several benefits:
>>  - unified interfaces and behavior with other platforms,
>>  - support for timer in one-shot mode,
>>  - more timer hardware can be easily supported (if there any).
>> Code works for me on UP sparc64 (SunBlade 100) and builds on sun4v.
>> Should work on SMP, but I can't test it.
>>
>> Patch for HEAD can be found here:
>> http://people.freebsd.org/~mav/timers_sparc.patch
>>
>> Any comments?
> 
> please don't commit this as-is:

That is why I am asking. :)

> - using the stick instead of the tick counter for machines with CPUs
>   and thus tick counters running at different speeds has turned out
>   to be suboptimal, probably due to the fact that the 12.5MHz the
>   stick counters typically are driven by don't provide sufficient
>   granularity.  

On x86 ACPI HPET timers often run about 15MHz, i8254 - about 1.2MHz.
What's wrong with 12.5MHz here?

>   Thus the more desireable variant for these machines
>   probably is to provide the tick counter of the BSP as the only
>   non-per-CPU timer and forward it to the APs via IPIs. 

It would be possible if timer was programmable from any CPU. But as I
understand - it require thread to be binded, which handled by
infrastructure only for per-CPU timer.

>   This also
>   leaves the stick counter of all >= US-III machines generally
>   available for driving statclock, which likely is also desirable.

It would be nice, but I don't know how separate their interrupts.

> - I'd like to keep the tick grace check as this caused problems in
>   the past. Probably tick_et_start() just should return an error
>   in this case.

I think it would be nice to move it to MI code. MI code knows about base
frequency, so theoretically can adapt to it. May be we could fetch some
additional info there, if needed. ACPI HPET timer also defines minimal
reliable period, so solution could/should be common.

> - I don't like wasting CPU cycles for determining whether the
>   workaround for BlackBird CPUs is needed (assuming #1 above is
>   implemented so distinguishing stick/tick is no longer needed)
>   with every (s)tick interrupt which are a lot as this just won't
>   ever change during runtime, i.e. I'd like to keep the different
>   interrupt handlers which are set up as needed.

Does it worth code duplication? Won't it be always cached/ predicted/
prefetched? I have doubt that difference can ever be measured, as this
function is minor part of things done on interrupt.

> - Replacing intr_disable_all() with intr_disable() on sun4v
>   probably isn't a good idea as the latter doesn't disable IPIs
>   as it does on sparc64 and other architectures.

Oops, just blind copy-paste.

Thank you.

-- 
Alexander Motin