Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 30 Mar 2010 19:43:46 +0300
From:      Andriy Gapon <avg@icyb.net.ua>
To:        John Baldwin <jhb@freebsd.org>
Cc:        freebsd-hackers@freebsd.org, =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= <des@des.no>
Subject:   Re: periodically save current time to time-of-day hardware
Message-ID:  <4BB22A42.7050003@icyb.net.ua>
In-Reply-To: <201003291044.28544.jhb@freebsd.org>
References:  <4BACC791.70502@icyb.net.ua> <20100327214634.GI32799@server.vk2pj.dyndns.org> <86fx3k7jqi.fsf@ds4.des.no> <201003291044.28544.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
on 29/03/2010 17:44 John Baldwin said the following:
> On Sunday 28 March 2010 7:45:25 am Dag-Erling Smørgrav wrote:
>> Peter Jeremy <peterjeremy@acm.org> writes:
>>> A new kthread which sleeps on channel "update_rtc".  When woken, it
>>> checks to see if it's within (say) 50msec of a second boundary and so,
>>> it does a trylock on the (new) RTC mutex.  If it grabs the mutex then
>>> it performs the update.  If it was too far from the second boundary or
>>> it fails to grab the mutex then it sleeps until the next second
>>> boundary and tries again.
>>>
>>> The existing resettodr() would then turn into a wakeup(update_rtc).
>> Sounds good to me, but if only that thread has access to the RTC, why
>> bother with a mutex?
> 
> I would dispense with the kthread and just use a callout (or have a callout 
> schedule a task for taskqueue_thread).

Guys,

do you think that periodic saving of system clock to hardware and making resettodr
asynchronous are dependent issues?  Or are they orthogonal and can be implemented
independently?

-- 
Andriy Gapon



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BB22A42.7050003>