From owner-freebsd-arch@FreeBSD.ORG Fri Sep 9 22:36:11 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C542E16A41F for ; Fri, 9 Sep 2005 22:36:11 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 399AA43D4C for ; Fri, 9 Sep 2005 22:36:11 +0000 (GMT) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id j89MfNdA066449; Fri, 9 Sep 2005 18:41:28 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Brooks Davis Date: Fri, 9 Sep 2005 18:35:50 -0400 User-Agent: KMail/1.6.2 References: <200509091744.26505.jkim@FreeBSD.org> <20050909214808.GA6021@odin.ac.hmc.edu> In-Reply-To: <20050909214808.GA6021@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_I5gIDbVAtC4Hjq/" Message-Id: <200509091835.52470.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.85.1/1073/Fri Sep 9 11:13:08 2005 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: freebsd-arch@FreeBSD.org Subject: Re: time_second vs. time_uptime X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2005 22:36:11 -0000 --Boundary-00=_I5gIDbVAtC4Hjq/ Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Friday 09 September 2005 05:48 pm, Brooks Davis wrote: > On Fri, Sep 09, 2005 at 05:44:24PM -0400, Jung-uk Kim wrote: > > If I read the source correctly, time_second can go backwards or > > forwards when there is a leap second but time_uptime cannot. Am > > I right? If my assumption is right, it seems we have some > > misuses in kernel, e. g., sched_sync() in sys/kern/vfs_subr.c. > > It may not be critical but it worries me a little because a leap > > second is scheduled to occur at the end of this year. ;-) > > Yes, uptime increases monotonically, but leap seconds and > adjustments such as those made by ntpdate will make simple time > values jump around. This bit me when I first did the interface > epochs since absolute times are not necessarily unique. It seems the most commonly misused places are networks stacks. It's understandable because time_uptime is relatively new. :-) http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_tc.c.diff?r1=1.140&r2=1.141 Anyway let's start fixing! Thanks, Jung-uk Kim --Boundary-00=_I5gIDbVAtC4Hjq/ Content-Type: text/x-diff; charset="euc-kr"; name="sched_sync.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="sched_sync.diff" Index: src/sys/kern/vfs_subr.c =================================================================== RCS file: /home/ncvs/src/sys/kern/vfs_subr.c,v retrieving revision 1.643 diff -u -r1.643 vfs_subr.c --- src/sys/kern/vfs_subr.c 28 Aug 2005 23:00:11 -0000 1.643 +++ src/sys/kern/vfs_subr.c 9 Sep 2005 22:25:42 -0000 @@ -1584,7 +1584,7 @@ syncer_final_iter = 0; first_printf = 1; syncer_state = SYNCER_RUNNING; - starttime = time_second; + starttime = time_uptime; EVENTHANDLER_REGISTER(shutdown_pre_sync, syncer_shutdown, td->td_proc, SHUTDOWN_PRI_LAST); @@ -1599,14 +1599,14 @@ } net_worklist_len = syncer_worklist_len - sync_vnode_count; if (syncer_state != SYNCER_RUNNING && - starttime != time_second) { + starttime != time_uptime) { if (first_printf) { printf("\nSyncing disks, vnodes remaining..."); first_printf = 0; } printf("%d ", net_worklist_len); } - starttime = time_second; + starttime = time_uptime; /* * Push files whose dirty time has expired. Be careful @@ -1695,7 +1695,7 @@ if (syncer_state != SYNCER_RUNNING) tsleep(&dummychan, PPAUSE, "syncfnl", hz / SYNCER_SHUTDOWN_SPEEDUP); - else if (time_second == starttime) + else if (time_uptime == starttime) tsleep(&lbolt, PPAUSE, "syncer", 0); } } --Boundary-00=_I5gIDbVAtC4Hjq/--