From owner-freebsd-arch@FreeBSD.ORG Wed Dec 17 19:56:17 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 02E5665F; Wed, 17 Dec 2014 19:56:17 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id B3C8012D6; Wed, 17 Dec 2014 19:56:16 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id 62F953BD3A; Wed, 17 Dec 2014 19:56:15 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id sBHJuEab070617; Wed, 17 Dec 2014 19:56:14 GMT (envelope-from phk@phk.freebsd.dk) To: Adrian Chadd Subject: Re: Change default VFS timestamp precision? In-reply-to: From: "Poul-Henning Kamp" References: <201412161348.41219.jhb@freebsd.org> <20141216233844.GA1490@stack.nl> <2034186.iLaW9EGnEt@ralph.baldwin.cx> <70073.1418837301@critter.freebsd.dk> <70449.1418843354@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <70615.1418846174.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Dec 2014 19:56:14 +0000 Message-ID: <70616.1418846174@critter.freebsd.dk> Cc: "freebsd-arch@freebsd.org" , Jilles Tjoelker X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 19:56:17 -0000 -------- In message , Adrian Chadd writes: >> A millisecond is pushing it, all things considered, it would have to >> be an utterly trivial source file for a utterly trivial language. > >Why? Computers can do a ridiculous amount of work in a millisecond. Yes, but try it yourself, they mostly don't. One millisecond is only about a million instructions if you are lucky, and in difference from system III, we have put an awful lot of code between the stuff you want done and the hardware that does it. So show me, and I'll belive you. >Right, but using TSP_NSEC only makes sense if (a) we get actual >nanosecond precision, and (b) we have some guarantee that when you >modify a file, the timestamp value is at least incremented by say, a >nanosecond. No. TSP_NSEC makes sense if TSP_HZ isn't enough, and it is the next logical step we can provide. If you want better than TSP_NSEC, the first thing to do is beat Intel and AMD up until the provide better timekeeping hardware in their CPUs. Once that's done, use this hardware for timecounters and TSP_NSEC will automatically improve. >I've been bitten by this - and I've had to hack things up to increment >a nanosecond counter to treat it as a poor mans generation counter, That's Lamports (in)famous solution :-) However, this doesn't really have *anything* to do with VFS timestamps, because there is NFW the objects you were timestamping were VFS files if nanosecond resolution were required. VFS timestamps are a performance trade-off, and if you want TSP_NSEC you can set TSP_NSEC, but for a sensible default TSP_HZ is the thing. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= .