From owner-freebsd-smp Sun Apr 5 06:20:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA17728 for freebsd-smp-outgoing; Sun, 5 Apr 1998 06:20:52 -0700 (PDT) (envelope-from owner-freebsd-smp@FreeBSD.ORG) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.14]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA17721 for ; Sun, 5 Apr 1998 06:20:49 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.5) with ESMTP id PAA07703; Sun, 5 Apr 1998 15:18:18 +0200 (CEST) To: Bruce Evans cc: peter@netplex.com.au, smp@FreeBSD.ORG Subject: Re: more SMP stuff In-reply-to: Your message of "Sun, 05 Apr 1998 23:06:05 +1000." <199804051306.XAA05313@godzilla.zeta.org.au> Date: Sun, 05 Apr 1998 15:18:17 +0200 Message-ID: <7701.891782297@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199804051306.XAA05313@godzilla.zeta.org.au>, Bruce Evans writes: >>>The scaling needs to be more robust since the h/w counter might be >>>slower than 10^6 hz. >> >>No, that is a design decision. Timecounter must be >= 1MHz. > >Why? The i8254 is only marginally faster than 1MHz. There's no >reason to expect a faster clock unless the CPU clock can be read. This is not NetBSD, we're looking at modern HW platforms, not needless and pointless generality... >>>It's used by my version of the floppy driver which calls microtime() >>>to timestamp certain events. >> >>before the i8254 is initialized ? > >In fdprobe(), before the i8254 is completely initialized. >>>I don't think I call nanotime() so early. My rtcintr() calls >>>nanotime() to gather statistics, and nanotime() was reentered. >>>I don't see any reentrancy problems. There will be one when >>>nanotime updates tc->nanotime like it should. >> >>No it shouldn't, I'm sorry but I cannot find a way where that makes >>fewer problems than it fixes... > >It is essential for POSIX.1 conformance and probably for `make' E.g., >the following shows chmod()+stat() sometimes updating the ctime of >a fifo apparently-before either is called. But the problem here is that the FS code uses the "cheap" version, not the correct version... They "shouldn't" do that... I can agree to update time_second in nanoµtime(), but not the tc->microtime & tc->nanotime, that is too expensive. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." "Drink MONO-tonic, it goes down but it will NEVER come back up!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message