On 01/17/17 20:46, Ian Lepore wrote:
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.


I propose the following patch then:

diff --git a/sys/kern/kern_clocksource.c b/sys/kern/kern_clocksource.c
index 7f7769d..5ae925b 100644
--- a/sys/kern/kern_clocksource.c
+++ b/sys/kern/kern_clocksource.c
@@ -511,8 +511,13 @@ configtimer(int start)
                        state->nexthard = next;
                        state->nextstat = next;
                        state->nextprof = next;
-                       state->nextcall = next;
-                       state->nextcallopt = next;
+                       /*
+                        * Force callout_process() to be called
+                        * instantly, so that the correct value of
+                        * "nextcall" can be computed:
+                        */
+                       state->nextcall = SBT_MAX;
+                       state->nextcallopt = now + 1;
                busy = 0;

Then there is no problem having to wait for the next tick or anything, like John Baldwin pointed out.

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to