Date: Thu, 9 Jul 2009 20:30:43 +0200 From: Thomas Backman <serenity@exscape.org> To: Andriy Gapon <avg@FreeBSD.org> Cc: freebsd-current@freebsd.org Subject: Re: dtrace users opinion solicited (timestamps) Message-ID: <732354CB-8FF2-4040-8ABD-B94076551C57@exscape.org> In-Reply-To: <4A563501.1090905@freebsd.org> References: <4A562960.3010801@freebsd.org> <D6516CB2-7FEA-4DD2-8177-A694BDABA3C7@exscape.org> <4A563501.1090905@freebsd.org>
index | next in thread | previous in thread | raw e-mail
On Jul 9, 2009, at 20:20, Andriy Gapon wrote: > on 09/07/2009 21:00 Thomas Backman said the following: >> On Jul 9, 2009, at 19:31, Andriy Gapon wrote: >>> There are at least the following two alternatives: >>> >>> 1. Keep things as they are and warn users not to change CPU clock >>> frequency when >>> they use DTrace and the CPU doesn't have invariant TSC. I think that >>> this should >>> cause only minor inconveniences to a portion of DTrace users. >> Hmm, but "things as they are" causes an overflow about every 10 >> seconds, >> so the value is quite useless now (which, of course, you know about, >> having written a patch for it :) > > This is because of a deficiency in the implementation of the > formula, not because > of the formula itself. > >> Is scenario #1 after the patch (PR kern/127441 for the rest of you) >> or not? > > Yes, after the patch :) In that case, I too strongly prefer alternative #1. It keeps the timestamp *time*-based, and not tick-based (thus not breaking Solaris/ OS X etc. compatibility), for one. It also makes it a whole lot easier to actually *time* things - is it even possible for a non-kernel- programmer DTrace user to easily convert the ticks to nanoseconds somewhat accurately? I think that's as good a reason as any (the first one, that is). If ZFS is kept as compatible as possible between OSes, then so should DTrace, IMHO. Regards, Thomashome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?732354CB-8FF2-4040-8ABD-B94076551C57>