linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hugh Dickins <hugh@veritas.com>
To: David Brownell <david-b@pacbell.net>
Cc: phdm@macqel.be, mpm@selenic.com, linux-kernel@vger.kernel.org
Subject: Re: RTC subsystem and fractions of seconds
Date: Sun, 7 Jan 2007 09:43:27 +0000 (GMT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0701070938500.13947@blonde.wat.veritas.com> (raw)
In-Reply-To: <20070107025425.0A7C21FAC07@adsl-69-226-248-13.dsl.pltn13.pacbell.net>

On Sat, 6 Jan 2007, David Brownell wrote:
> > > Hmm ... "looping" fights against "quickly"; as would "wait for next
> > > update IRQ" (on RTCs that support that).  But it would improve precision,
> > > at least in the sense of having the system clock and that RTC spending
> > > less time with the lowest "seconds" digit disagreeing.
> > > 
> > > This is something you could write a patch for, n'est-ce pas?
> >
> > If you're thinking of going that way,
> 
> Philippe seemed to be ...
> 
> >	it'd be courteous to CC Matt,
> > who devoted some effort to removing just that loop in 2.6.17 ;)
> 
> Hmm ... "git whatchanged drivers/rtc/hctosys.c" shows no such change.
> So I can't find any record of such a change or its rationale.

Perhaps I'm muddled - I was thinking of this and its associates:

commit 63732c2f37093d63102d53e70866cf87bf0c0479
Author: Matt Mackall <mpm@selenic.com>
Date:   Tue Mar 28 01:55:58 2006 -0800

    [PATCH] RTC: Remove RTC UIP synchronization on x86
    
    Reading the CMOS clock on x86 and some other arches currently takes up to one
    second because it synchronizes with the CMOS second tick-over.  This delay
    shows up at boot time as well a resume time.
    
    This is the currently the most substantial boot time delay for machines that
    are working towards instant-on capability.  Also, a quick back of the envelope
    calculation (.5sec * 2M users * 1 boot a day * 10 years) suggests it has cost
    Linux users in the neighborhood of a million man-hours.
    
    An earlier thread on this topic is here:
    
    http://groups.google.com/group/linux.kernel/browse_frm/thread/8a24255215ff6151/2aa97e66a977653d?hl=en&lr=&ie=UTF-8&rnum=1&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3D1To2R-2S7-11%40gated-at.bofh.it#2aa97e66a977653d
    
    ..from which the consensus seems to be that it's no longer desirable.
    
    In my view, there are basically four cases to consider:
    
    1) networked, need precise walltime: use NTP
    2) networked, don't need precise walltime: use NTP anyway
    3) not networked, don't need sub-second precision walltime: don't care
    4) not networked, need sub-second precision walltime:
       get a network or a radio time source because RTC isn't good enough anyway
    
    So this patch series simply removes the synchronization in favor of a simple
    seqlock-like approach using the seconds value.
    
    Note that for purposes of timer accuracy on wakeup, this patch will cause us
    to fire timers up to one second late.  But as the current timer resume code
    will already sync once (or more!), it's no worse for short timers.
    
    Signed-off-by: Matt Mackall <mpm@selenic.com>
    Cc: Andi Kleen <ak@muc.de>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: Paul Mackerras <paulus@samba.org>
    Cc: Russell King <rmk@arm.linux.org.uk>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: Paul Mundt <lethal@linux-sh.org>
    Cc: Kazumoto Kojima <kkojima@rr.iij4u.or.jp>
    Cc: Alessandro Zummo <a.zummo@towertech.it>
    Signed-off-by: Andrew Morton <akpm@osdl.org>
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>

diff --git a/include/asm-i386/mach-default/mach_time.h b/include/asm-i386/mach-default/mach_time.h
index b749aa4..ff03cf0 100644
--- a/include/asm-i386/mach-default/mach_time.h
+++ b/include/asm-i386/mach-default/mach_time.h
@@ -82,21 +82,8 @@ static inline int mach_set_rtc_mmss(unsi
 static inline unsigned long mach_get_cmos_time(void)
 {
 	unsigned int year, mon, day, hour, min, sec;
-	int i;
 
-	/* The Linux interpretation of the CMOS clock register contents:
-	 * When the Update-In-Progress (UIP) flag goes from 1 to 0, the
-	 * RTC registers show the second which has precisely just started.
-	 * Let's hope other operating systems interpret the RTC the same way.
-	 */
-	/* read RTC exactly on falling edge of update flag */
-	for (i = 0 ; i < 1000000 ; i++)	/* may take up to 1 second... */
-		if (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP)
-			break;
-	for (i = 0 ; i < 1000000 ; i++)	/* must try at least 2.228 ms */
-		if (!(CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP))
-			break;
-	do { /* Isn't this overkill ? UIP above should guarantee consistency */
+	do {
 		sec = CMOS_READ(RTC_SECONDS);
 		min = CMOS_READ(RTC_MINUTES);
 		hour = CMOS_READ(RTC_HOURS);
@@ -104,6 +91,7 @@ static inline unsigned long mach_get_cmo
 		mon = CMOS_READ(RTC_MONTH);
 		year = CMOS_READ(RTC_YEAR);
 	} while (sec != CMOS_READ(RTC_SECONDS));
+
 	if (!(CMOS_READ(RTC_CONTROL) & RTC_DM_BINARY) || RTC_ALWAYS_BCD)
 	  {
 	    BCD_TO_BIN(sec);

  reply	other threads:[~2007-01-07  9:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-06  3:49 RTC subsystem and fractions of seconds David Brownell
2007-01-06 23:26 ` Philippe De Muyter
2007-01-06 23:52   ` David Brownell
2007-01-07  1:11     ` Hugh Dickins
2007-01-07  2:54       ` David Brownell
2007-01-07  9:43         ` Hugh Dickins [this message]
2007-01-07 10:02     ` Philippe De Muyter
2007-01-07 10:14 ` Philippe De Muyter
2007-01-08  2:10   ` David Brownell
2007-01-08 10:25     ` Philippe De Muyter
  -- strict thread matches above, loose matches on Subject: below --
2007-01-07 22:31 Philippe De Muyter
2007-01-06  2:29 Philippe De Muyter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0701070938500.13947@blonde.wat.veritas.com \
    --to=hugh@veritas.com \
    --cc=david-b@pacbell.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpm@selenic.com \
    --cc=phdm@macqel.be \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).