From owner-freebsd-arch@FreeBSD.ORG Thu Dec 18 19:49:33 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 42D1B5E5; Thu, 18 Dec 2014 19:49:33 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1AFFC1695; Thu, 18 Dec 2014 19:49:33 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 97EB0B945; Thu, 18 Dec 2014 14:49:31 -0500 (EST) From: John Baldwin To: "Poul-Henning Kamp" Subject: Re: Change default VFS timestamp precision? Date: Thu, 18 Dec 2014 14:36:31 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <201412161348.41219.jhb@freebsd.org> <70449.1418843354@critter.freebsd.dk> In-Reply-To: <70449.1418843354@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201412181436.31701.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 18 Dec 2014 14:49:31 -0500 (EST) Cc: "freebsd-arch@freebsd.org" , Adrian Chadd , 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: Thu, 18 Dec 2014 19:49:33 -0000 On Wednesday, December 17, 2014 2:09:14 pm Poul-Henning Kamp wrote: > -------- > In message > , Adrian Chadd writes: > > >> I think it is over 10 years ago when make(1) first started seeing > >> identical timestamps which wasn't. > >> > >> In most Makefiles this doesn't matter, but there are cases, in particular > >> in less integrated families of makefiles than our own. > > > >Surely there has to be better ways of doing this stuff. Computers keep > >getting faster; it wouldn't be out of the realm of possibility that we > >could see a compiler read, compile and spit out a .o inside of a > >millisecond. (Obviously not C++, but..) > > A millisecond is pushing it, all things considered, it would have to > be an utterly trivial source file for a utterly trivial language. > > Given that it has epsilon cost, switching to TSP_HZ should be a > no-brainer, I've been running that for ages. > > Why TSP_USEC exists is beyond me, it's slower and worse than TSP_NSEC. > > But going to TSP_NSEC by default seems unwarranted to me. Eh, the use case I most care about is back-to-back updates to a directory on an NFS server. Those can certainly occur quite quickly and in under a millisecond (e.g. rm foo* in a directory is going to be multiple unlink() calls each of which will update the mtime of the directory). I don't understand why you think TSP_USEC is slower than TSP_NSEC. microtime() and nanotime() both just call bintime() and then convert the result using similar math. However, I think I buy Jilles' argument that TSP_USEC is likely to give more stable results (i.e. increasing mtime) if back to back updates are performed across CPUs (assuming some amount of TSC jitter for example). -- John Baldwin