From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20434 invoked by alias); 24 Jan 2007 19:32:51 -0000 Received: (qmail 20289 invoked by uid 48); 24 Jan 2007 19:32:24 -0000 Date: Wed, 24 Jan 2007 19:32:00 -0000 Message-ID: <20070124193224.20288.qmail@sourceware.org> From: "fche at redhat dot com" To: systemtap@sources.redhat.com In-Reply-To: <20070124160955.3916.fche@redhat.com> References: <20070124160955.3916.fche@redhat.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug runtime/3916] improve timing monotony X-Bugzilla-Reason: AssignedTo Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2007-q1/txt/msg00193.txt.bz2 ------- Additional Comments From fche at redhat dot com 2007-01-24 19:32 ------- (In reply to comment #1) > Possible solutions: > * Find a better estimate of the cpu freq > * Use a clock that's independent of cpu freq (e.g., a motherboard/chipset timer) > * Get the kernel to provide a lockless gettimeofday > * Others? One simple thing is to keep the per-cpu counts from ever decreasing during the resynchronization phase. This could let them drift ahead of real time, but so be it. If it gets too bad, the runtime could emit a warning. Also, the resync phase may not be necessary so frequently on stable_tsc processors. -- http://sourceware.org/bugzilla/show_bug.cgi?id=3916 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.