From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 18:20:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64EE810656A8 for ; Thu, 9 Jul 2009 18:20:53 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A534D8FC19 for ; Thu, 9 Jul 2009 18:20:52 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA17045; Thu, 09 Jul 2009 21:20:50 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4A563501.1090905@freebsd.org> Date: Thu, 09 Jul 2009 21:20:49 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.22 (X11/20090630) MIME-Version: 1.0 To: Thomas Backman References: <4A562960.3010801@freebsd.org> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: dtrace users opinion solicited (timestamps) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 18:20:53 -0000 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 :) -- Andriy Gapon