Date: Thu, 18 Dec 2014 14:36:31 -0500 From: John Baldwin <jhb@freebsd.org> To: "Poul-Henning Kamp" <phk@phk.freebsd.dk> Cc: "freebsd-arch@freebsd.org" <arch@freebsd.org>, Adrian Chadd <adrian@freebsd.org>, Jilles Tjoelker <jilles@stack.nl> Subject: Re: Change default VFS timestamp precision? Message-ID: <201412181436.31701.jhb@freebsd.org> In-Reply-To: <70449.1418843354@critter.freebsd.dk> References: <201412161348.41219.jhb@freebsd.org> <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 Wednesday, December 17, 2014 2:09:14 pm Poul-Henning Kamp 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. > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201412181436.31701.jhb>