Date: Thu, 19 Mar 2009 12:55:11 +0000 (UTC) From: Marius Strobl <marius@FreeBSD.org> To: cvs-src-old@freebsd.org Subject: cvs commit: src/sys/sparc64/include clock.h cpufunc.h pcpu.h smp.h tick.h ver.h src/sys/sparc64/sparc64 clock.c exception.S genassym.c locore.S machdep.c mp_locore.S mp_machdep.c tick.c Message-ID: <200903191255.n2JCtOi1058581@repoman.freebsd.org>
index | next in thread | raw e-mail
marius 2009-03-19 12:55:11 UTC
FreeBSD src repository
Modified files: (Branch: RELENG_7)
sys/sparc64/include clock.h cpufunc.h pcpu.h smp.h tick.h
ver.h
sys/sparc64/sparc64 clock.c exception.S genassym.c locore.S
machdep.c mp_locore.S mp_machdep.c tick.c
Log:
SVN rev 190033 on 2009-03-19 12:55:11Z by marius
MFC: r182730, r182743, r183201
- USIII-based machines can consist of CPUs running at different
frequencies (and having different cache sizes) so use the STICK
(System TICK) timer, which was introduced due to this and is
driven by the same frequency across all CPUs, instead of the
TICK timer, whose frequency varies with the CPU clock, to drive
hardclock. We use the STICK timers only when absolutely necessary
though as the STICK timers are driven at frequencies as low as
5MHz, resulting in bad granularity compared to the TICK timers.
However, don't employ the workaround for the BlackBird erratum #1
when using the TICK timer on machines with cheetah-class CPUs for
performance reasons.
Note that using the STICK counter also causes a hang with USIIIi
MP machines for reasons unknown, but these can only consist of
identical CPUs anyway.
- Given that we only (try to) synchronize the (S)TICK timers of APs
with the BSP during startup, we could end up spinning forever in
DELAY(9) if that function is migrated to another CPU while we're
spinning due to clock drift afterwards, so pin to the CPU in order
to avoid migration. Unfortunately, pinning doesn't work at the
point DELAY(9) is required by the low-level console drivers, yet,
so switch to a function pointer, which is updated accordingly, for
implementing DELAY(9). For USIII and beyond, this would also allow
to easily use the STICK counter instead of the TICK one here,
there's no benefit in doing so however.
While at it, use cpu_spinwait(9) for spinning in the delay-
functions. This currently is a NOP though.
- Don't set the TICK timer of the BSP to 0 during startup as there's
no need to do so.
- Implement cpu_est_clockrate().
- Unfortunately, USIIIi-based machines don't provide a timecounter
device besides the STICK and TICK counters (well, in theory the
Tomatillo bridges have a performance counter that can be (ab)used
as timecounter by configuring it to count bus cycles, though unlike
the performance counter of Schizo bridges, the Tomatillo one is
broken and counts Sun knows what in this mode). This means that
we've to use a (S)TICK counter for timecounting, which has the old
problem of not being in sync across CPUs, so provide an additional
timecounter function which binds itself to the BSP but has an
adequate low priority.
Revision Changes Path
1.7.2.1 +6 -4 src/sys/sparc64/include/clock.h
1.21.2.3 +9 -0 src/sys/sparc64/include/cpufunc.h
1.22.2.4 +1 -0 src/sys/sparc64/include/pcpu.h
1.22.2.2 +5 -3 src/sys/sparc64/include/smp.h
1.4.10.1 +3 -1 src/sys/sparc64/include/tick.h
1.6.2.1 +4 -0 src/sys/sparc64/include/ver.h
1.10.22.2 +42 -9 src/sys/sparc64/sparc64/clock.c
1.75.2.2 +1 -1 src/sys/sparc64/sparc64/exception.S
1.70.2.2 +3 -2 src/sys/sparc64/sparc64/genassym.c
1.22.2.2 +0 -1 src/sys/sparc64/sparc64/locore.S
1.138.2.5 +39 -44 src/sys/sparc64/sparc64/machdep.c
1.8.2.2 +25 -9 src/sys/sparc64/sparc64/mp_locore.S
1.36.2.6 +13 -3 src/sys/sparc64/sparc64/mp_machdep.c
1.22.2.2 +184 -52 src/sys/sparc64/sparc64/tick.c
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200903191255.n2JCtOi1058581>