[RFC] Event timers on sparc64/sun4v

[Marius Strobl]

On Wed, Jul 28, 2010 at 10:26:42AM +0300, Alexander Motin wrote:
> Marius Strobl wrote:
> > On Wed, Jul 21, 2010 at 03:10:35PM +0300, Alexander Motin wrote:
> >> Here is updated patch for latest HEAD, which should handle this:
> >> http://people.freebsd.org/~mav/timers_sparc4.patch
> >>
> >> I also added support for STICK timecounter. For this moment with lowest
> >> priority to not use it by default, until it is tested.
> > 
> > The patch looks ok and seems to work as expected on MP US-IIIi.
> > However, I'd suggest to just use TICK_QUALITY_{M,U}P for the
> > quality of the STICK timecounter but negated for now; I see no
> > reason why the STICK timecounter should be of any other quality
> > (from the hardware point of view) than the TICK one and whatever
> > the solution is to make the TICK timecounter work with locks etc
> > also needs to be applied to the STICK one (maybe on some machines
> > the synchronicity across CPUs actually happens to be sufficient
> > but I'd like to rather not make any assumptions about machines
> > that f.e. group CPUs by coherency domain etc).
> 
> As you said before, STICK has lower resolution then TICK (though not so
> much), so I would set it's quality a bit lower.

Correct, depending on model it's driven by a frequency between
5 and 20MHz. However, as far as the MI part of the timecounter
code is concerned quality and frequency, i.e. resolution, are
orthogonal. If two timecounters have the same quality but are
driven by different frequencies the timecounter with the better
resolution is preferred, i.e. the resolution shouldn't be
reflected by the quality parameter.

> And it has more chances
> to work synchronously then TICK on MP, so I would set it's quality
> higher there. I don't actually see the reason for using negative
> qualities, unless timers are really broken. In such case if there will
> be no other timers, system will fall back to the dummy, which I have
> doubts is better then anything else.

I don't see a practical difference between TICK and STICK based
timecounters in the MP case as far as synchronicity is concerened;
the latter might have (well, in case the CPUs are running at
different speeds it actually has) a better synchronicity but we
just can't assume this and in order to provide a stable timecounter
we need to bind reading the (S)TICK count to a CPU anyway, in which
case both have the same quality. The reason I suggest a negative
qualitiy is that your patch is missing binding reading the STICK
count to CPU, i.e. is broken in the MP case. I wouldn't worry
about binding this to the BSP too much, even if this means that
further down the road this has negative impact on running a
tickless kernel as this only affects some low-cost (or at least
what low-cost is to Sun) models which have no alternative to
using the (S)TICK timecounter (there is some price to pay
after all ...).

Marius