[RFC] Event timers on sparc64/sun4v

[Marius Strobl]

On Sun, Jul 18, 2010 at 09:56:57AM +0300, Alexander Motin wrote:
> Marius Strobl wrote:
> > please don't commit this as-is:
> > - 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. 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. This also
> >   leaves the stick counter of all >= US-III machines generally
> >   available for driving statclock, which likely is also desirable.
> > - 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 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.
> > - 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.
> 
> Here is new path, updated respecting two last points:
> http://people.freebsd.org/~mav/timers_sparc2.patch

Looks better, but can't you just implement the tick grace check
in tick_et_start() and let it return an error if the interval
is too short until there maybe is an MI way to supply a minimum
period?
Also please follow style(9) and don't initializing variables in
the declarations and leave tick_{clear,start} at the end of the
file in order to not move code around unnecessarily.

> 
> Don't you have some spare system with stick problems, so I could play
> with it?

I have but I recently moved and am currently busy with semester
finals so it'll probably be mid-August when I'm able to set it up
again. I'm not sure I'll be able to provide remote access though.

> And some documentation? I am curious, what is wrong there. :)

Just look at the documentation of US-III or later CPUs:
www.cs.pitt.edu/~cho/cs2410/currentsemester/handouts/USIIIv2.pdf

Marius