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. -- IanReceived on Tue Jan 17 2017 - 18:47:39 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:09 UTC