Strange issue after early AP startup

[Ian Lepore]

On Tue, 2017-01-17 at 11:00 -0800, John Baldwin wrote:
> >  > You could
> >  > do that by setting it to 'cc_firstevent' of the associated CPU, but in
> >  > practice 'state->nextcall' should already be set to that (it is 
> > initalized
> >  > to SBT_MAX in cpu_initclocks_bsp() and is then only set to other 
> > values due
> >  > to cpu_new_callout()).  Keep in mind that configtimer() is not just 
> > called
> >  > from boot, but is also invoked when starting/stopping the profiling 
> > timer.
> >  >
> > 
> >  > However, when setting 'nextevent' (which is used to schedule the next 
> > timer
> >  > interrupt), we should be honoring the existing 'nextcall' if it is sooner
> >  > than the next hardclock.
> > 
> > Does this matter for the first tick? How often is configtimer() called?
> 
> As I said, it is called at runtime when profclock is started / stopped, not
> just at boot.  Those changes at runtime probably have existing callouts
> active and your change will not process any callouts until the next hardclock
> tick fires (but only because you are setting nextcallopt to the bogus
> 'next' value).

On some platforms, configtimer() can be called quite often.  Power
saving modes can change the frequency of the timer, and systems that
suppport such dynamic frequency scaling call configtimer()
(via cpu_et_frequency()) to handle the changes.

-- Ian