From owner-freebsd-arch@FreeBSD.ORG Wed Dec 17 19:31:42 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 641B3DF; Wed, 17 Dec 2014 19:31:42 +0000 (UTC) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 07288101D; Wed, 17 Dec 2014 19:31:42 +0000 (UTC) Received: by mail-wg0-f48.google.com with SMTP id y19so21134212wgg.21 for ; Wed, 17 Dec 2014 11:31:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ZnU9xTt+nNOAIlBQum8n8tcpZ8SEcD5XijswDD2lRnI=; b=piqdKUaXqhgFj3AVcezJjKlLYlIrZvH2GfFqftA11UbmhqItOV2poiKFRt70Q/N3aj /5TTWB41Sv0vjoSFyDDKczSFDBs5FFwCYy/HT4mDPTAusvJ/laKNkK6j+SZKGBVtz85k esk/RSepREVSMLB+yyVeEeTV07jN7R8YHYKTP/5Bkp/KZo5iNiuommY+3cNEbY7tdAs1 4NgGOivHiZcN7C1E23m6fQdk21dwH+tkIYKvUE3IgqVP9LPaW1NGkSy32xP6ktDCXR0O QmqVkgx32vdG/fW734Y2/zdDnQGg03kujzBTcvX+0GXp02zlfFZbWBfErF8aSeolkvrG UDrw== MIME-Version: 1.0 X-Received: by 10.194.85.83 with SMTP id f19mr77193878wjz.20.1418844700455; Wed, 17 Dec 2014 11:31:40 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.106.195 with HTTP; Wed, 17 Dec 2014 11:31:40 -0800 (PST) In-Reply-To: <70449.1418843354@critter.freebsd.dk> 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> Date: Wed, 17 Dec 2014 11:31:40 -0800 X-Google-Sender-Auth: coSxUwqbecx51C2SFQuRs7iaxfE Message-ID: Subject: Re: Change default VFS timestamp precision? From: Adrian Chadd To: Poul-Henning Kamp Content-Type: text/plain; charset=UTF-8 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:31:42 -0000 On 17 December 2014 at 11:09, 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. Why? Computers can do a ridiculous amount of work in a millisecond. Assuming you're doing something daft like compiling a large C++ thing, the actual inefficiencies that bites you is all the overhead in fork, exec, demand paging in things, setting it up, etc. If your file generation is instead from some persistent "thing" that's not fork/exec/faulting/setup/teardown/writing/syncing and it's translating from source X to representation Y (and this can be a compiler, but I was doing this with some linguistic hacks whilst at uni) a lot of work gets done in that millisecond. > 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. 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. Rather than the rather silly setup where you ask for NSEC or USEC (or heck, MSEC) and you end up changing a file very rapidly within the resolution of the timecounter API being used. 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, documenting that if you change this object more than say a million times a second, you may hit issues. (All because things don't have a generational counter, they have a timestamp, and computers got really fast really quickly.) -adrian