On Sat, Aug 19, 2023 at 01:44:47PM -0500, Scott Cheloha wrote:
> On Sun, Aug 13, 2023 at 01:48:21PM -0500, Scott Cheloha wrote:
> > This is the next patch in the clock interrupt reorganization series.
> > 
> > Before we continue breaking up the hardclock(9) we need to detour into
> > the MD code.
> > 
> > This patch divides the "initialization" parts of cpu_initclocks() from
> > the "start the clock interrupt" parts.  Seprating the two parts leaves
> > initclocks() an opportunity to prepare the primary CPU for clock
> > interrupt dispatch in a machine-independent manner before actually
> > pulling the trigger.  It's nearly impossible to do any MI setup during
> > initclocks() because cpu_initclocks() does everything in one go: both
> > initialization and kickoff are done when cpu_initclocks() returns.
> > 
> > Many platforms have a "cpu_startclock()" function, so this patch takes
> > that de facto standard and makes it a rule: cpu_startclock() is now
> > required.  It is prototyped in sys/systm.h and every platform must
> > implement it.
> > 
> > The revised initclocks() sequence is then:
> > 
> > 1. Call cpu_initclocks().  At minimum, cpu_initclocks() ensures
> >    hz, stathz, and profhz are initialized.  All the machine
> >    independent setup in step (2) (currently) depends upon
> >    these machine-dependent values.
> > 
> > 2. Compute intervals using hz, stathz, and profhz.
> > 
> >    In a later step I will move the full contents of clockintr_init()
> >    up into initclocks() and get rid of clockintr_init() entirely.
> > 
> > 3. Call cpu_startclock().  At minimum, cpu_startclock() starts the
> >    clock interrupt dispatch cycle on the primary CPU.
> > 
> > I have compiled/booted this patch on amd64 (lapic path), arm64, i386
> > (lapic path), macppc, octeon, and sparc64 (sun4v).
> > 
> > I am looking for compile/boot tests on alpha, armv7, hppa, landisk,
> > luna88k, powerpc64, and riscv64.  I think armv7 is the tricky one
> > here.  Everything else is relatively straightforward, though I may
> > have missed a few stray variables here or there.
> > 
> > Test results?  Ok?
> 
> Here is an updated patch that removes several MD prototypes for
> cpu_startclock() that I missed the first time through.
> 
> I went back and tested these again:
> 
> - amd64 (lapic)
> - arm64
> - i386 (lapic)
> - powerpc/macppc
> - mips64/octeon (loongson should be fine)
> - sparc64 (sys_tick; tick/stick should be fine)
> 
> arm/armv7 and riscv64 were tested under the previous version, but I
> would appreciate a second compile-test to make sure the header changes
> in the updated patch did not break the build (CC phessler@, jsg@).

Still builds on riscv64 and armv7.

Reply via email to