Daniel Carosone wrote:
> On Thu, Sep 07, 2006 at 09:17:33PM -0400, Perry E. Metzger wrote:
>   
>> The system clock is often being conditioned by something like NTP. The
>> reason for writing back the RTC when a change in the system clock
>> happens or another event that triggers resettodr is to assure that
>> they stay in sync so the next reboot gets the benefit of whatever is
>> conditioning the clock.
>>     
>
> So, in the normal case (shutdown aside), todr resets should be
> scheduled and actually done in a callout (or similar) that happens as
> close as possible to the second boundary.
>
> For the shutdown case, the question becomes whether to wait for that
> to have run before callout processing is stopped.  That could be an
> option/sysctl.  If the reset is scheduled early enough in the
> shutdown/suspend routine, there's a reasonable chance it will have run
> anyway by the time other things (like unmounting/quiescing
> filesystems, saving driver state, etc) have happened.
>
> And, by Richard's argument, it doesn't really matter if it hasn't as
> long as updates have happened recently enough during normal running.
>
> Which really just leaves the question of how to align with second
> transition at startup.  
>
> --
> Dan.
>   

I agree that during settimeofday(2), we should use a callout to schedule
it as closely to a second as possible.

Shutdown, suspend, and startup are harder.  I suggest that we are
over-engineering the problem.  A one second delay at each of these times
is the _worst_ case scenario.  I would be very surprised if anyone
noticed a one second delay at these times.

Furthermore, some clocks might actually support better time resolution
than 1 second.  The todr calls can support up to microsecond resolution.

Frankly, overall system performance implications by additional code to
do the scheduling, plus all the testing to make sure nothing is busted,
pushes me even more strongly away from this.

Therefore, my recommendation is to skip all this effort attempting to
shave off that second, and spend it somewhere where the effort will
contribute to run-time performance.

A better way to improve boot time and shutdown performance, IMO, is to
figure out how to parallelize some things like startup scripts.  I
suspect that a lot can be run in parallel that currently isn't. 
(Solaris 10 and MacOS X I think each have demonstrated that.)

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191