Date: Wed, 17 Dec 2014 11:31:40 -0800 From: Adrian Chadd <adrian@freebsd.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: "freebsd-arch@freebsd.org" <arch@freebsd.org>, Jilles Tjoelker <jilles@stack.nl> Subject: Re: Change default VFS timestamp precision? Message-ID: <CAJ-Vmokom24Hv1MNNJz2t_bL_o7X%2BW6FgXaPXT2Q3gSurKefcg@mail.gmail.com> 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> <CAJ-Vmokkc-p4-keMExxT%2BwyjugA8zYRS2XRv6VucWnfH0iw_Pw@mail.gmail.com> <70449.1418843354@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 17 December 2014 at 11:09, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > -------- > In message <CAJ-Vmokkc-p4-keMExxT+wyjugA8zYRS2XRv6VucWnfH0iw_Pw@mail.gmail.com> > , 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmokom24Hv1MNNJz2t_bL_o7X%2BW6FgXaPXT2Q3gSurKefcg>