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.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"